IIS 8.5 单工作进程与 Web Garden 性能答案

【问题标题】：IIS 8.5 single worker process vs Web Garden performanceIIS 8.5 单工作进程与 Web Garden 性能
【发布时间】：2017-05-16 14:29:49
【问题描述】：

我有一个简单的 ASP.NET 应用程序，它只使用 ImageResizer 调整图像大小，而没有做任何其他事情。出于测试目的，我禁用了磁盘缓存，因此每次请求都会调整图像大小。

当我使用 JMeter 测试应用程序的性能时，我得到以下平均响应时间：

如您所见，当我运行单个工作进程和 10 个并发客户端时，尽管有可用的硬件资源，但响应时间显着增加：性能测试期间的 CPU 使用率约为 30%，内存使用率约为 150MB。

正如here所讨论的，

网络花园的设计目的只有一个——提供应用程序不受 CPU 限制但执行长时间运行的请求的能力扩展而不用尽工作进程中可用的所有线程。

这似乎不是我的情况。

我不明白为什么我会得到这样的结果。我期望的是，即使是单个工作进程也会提供可接受的响应时间，直到它达到资源限制。并且 10 个并发客户端绝对不是一个沉重的负担。谁能给我解释一下，我哪里错了？

我的配置：

我的应用程序只是带有 ImageResizer 的空 ASP.NET MVC 应用程序，在 this instruction 中添加（选项 3 - 手动安装）并在 Web.config 中禁用了 DiskCache 插件

【问题讨论】：

仅根据您提供的这些数字，并且对 ImageResizer 一无所知，看起来 ImageResizer 正在单个线程中运行调整大小操作，也许是 STA？如果它基于不支持多线程的 COM 组件，则可能是这种情况。

【解决方案1】：

感谢@Ben 的评论，我找到了答案。

问题是 ImageResizer 基于 GDI+（如 it's site 所述），其中包含内部锁（有关详细信息，请参阅 this 和 this 帖子）。这就是为什么它在单个进程中运行如此缓慢的原因。

找到问题原因后，我尝试了this solution。从 ASP.NET 应用程序引用 WPF 程序集可能不是一个最佳主意，但它可以用于测试目的。

现在，当我执行与问题相同的性能测试时，我得到以下结果：

如您所见，现在应用程序运行得更快了。正如我最初预期的那样，它在高负载下利用了几乎所有可用的 CPU 资源。

因此，如果您在 ASP.NET 应用程序中处理图像：

如果可以，请不要使用基于 GDI+ 的解决方案

如果必须使用 GDI+，请在应用程序池的设置中增加 MaxWorkerProcesses

【讨论】：