asp.net - IIS 8.5 单工作进程与 Web Garden 性能

Question

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

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

• 单个工作进程，1 个并发客户端:约 200 毫秒
• 单个工作进程，10 个并发客户端:约 1200 毫秒
• 4 个工作进程，10 个并发客户端:约 300 毫秒

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

正如所讨论的here ,

Web gardens was designed for one single reason – Offering applications that are not CPU-bound but execute long running requests the ability to scale and not use up all threads available in the worker process.

这似乎不是我的情况。

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

我的配置:

• Windows Server 2012 R2
• 具有所有默认设置的 IIS 8.5(MaxWorkerThreads 除外)
• 四核 i3 3.4GHz CPU
• 16 GB 内存

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

Answer 1

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

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

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

现在，当我执行与所讨论的相同的性能测试时，我得到以下结果:

• 单个工作进程，1 个并发客户端:约 90 毫秒
• 单个工作进程，10 个并发客户端:约 120 毫秒
• 单个工作进程，40 个并发客户端:约 190 毫秒
• 单个工作进程，60 个并发客户端:约 400 毫秒
• 单个工作进程，80 个并发客户端:约 630 毫秒

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

So, if you process images in your ASP.NET application:

• don't use GDI+ based solution, if you can
• if you have to use GDI+, increase MaxWorkerProcesses in applicaion pool's settings