IIS 8.5单一工作进程与Web Garden性能比较

Question

6

我有一个简单的ASP.NET应用程序，只使用ImageResizer调整图像大小，没有其他操作。为了测试目的，我禁用了磁盘缓存，因此每次请求都会调整图像大小。

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

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

可以看出，当我运行单个工作进程和10个并发客户端时，尽管硬件资源可用，响应时间显著增加：性能测试期间CPU使用率约为30％，内存使用率为约150MB。

正如此处所讨论的，

“Web garden的设计初衷是为了提供不受CPU限制但执行长时间请求的应用程序扩展能力，并且不会使用工作进程中的所有线程。”

这与我的情况似乎不符。

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

我的配置：

- Windows Server 2012 R2 - IIS 8.5（除了MaxWorkerThreads之外所有默认设置） - 四核i3 3.4GHz CPU - 16 GB RAM

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

- Marat Safin

1

仅基于您提供的这些数字，而不知道任何关于ImageResizer的信息，看起来ImageResizer正在单线程中运行调整大小操作，可能是STA？如果它是基于不支持多线程的COM组件构建的，那么这种（推测）情况可能是这样。 - Ben

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Marat Safin · Accepted Answer

在@Ben的评论的帮助下，我找到了答案。

问题出在ImageResizer是基于GDI+（如它的网站所述），其中包含锁定（有关详细信息，请参见this和this）。这就是为什么单个进程中它工作得如此缓慢的原因。

找到问题的原因后，我尝试了this solution。从ASP.NET应用程序引用WPF程序集可能不是一个最好的想法，但对于测试目的来说还可以接受。

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

正如您所看到的，现在应用程序的工作速度更快了。在高负载下，它还利用了几乎所有可用的CPU资源，这正是我最初预期的。

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

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

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