我有简单的ASP.NET应用程序，它只使用ImageResizer调整图像大小，并且不执行任何其他操作。出于测试目的，我禁用了磁盘缓存，因此每次请求都会调整图像大小。
当我使用JMeter测试应用程序的性能时，我得到以下平均响应时间：
正如您所看到的，当我运行单个工作进程和10个并发客户端时，尽管有可用的硬件资源，响应时间也会急剧增加：性能测试期间的CPU使用率约为30％，内存使用量约为150MB。
正如here所述，
网络花园的设计原因只有一个 - 提供应用程序 不受CPU限制但执行长时间运行请求的能力 扩展并且不会耗尽工作进程中可用的所有线程。
这不像我的情况。
我不明白为什么会得到这样的结果。我所期望的是，即使是单个工作进程也会提供可接受的响应时间，直到达到资源限制。 10个并发客户端绝对不是一个重负载。有人可以向我解释，我错在哪里吗？
我的配置：
我的应用程序只是带有ImageResizer的空ASP.NET MVC应用程序，在this instruction中添加（选项3 - 手动安装）并在Web.config中禁用了DiskCache插件
答案 0 :(得分：4)
感谢@ Ben的评论，我找到了答案。
问题是ImageResizer基于GDI +（如it's site所述），其中包含内部锁（有关详细信息，请参阅this和this帖子）。这就是为什么它在单个过程中工作得如此缓慢。
找到问题的原因后我试了this solution。从ASP.NET应用程序引用WPF程序集可能不是最好的主意，但它可以用于测试目的。
现在，当我执行与问题相同的性能测试时，我得到以下结果：
如您所见，现在应用程序运行得更快。此外，它在高负载下利用几乎所有可用的CPU资源，正如我最初预期的那样。
因此，如果您在ASP.NET应用程序中处理图像：
- 如果可以
，请不要使用基于GDI +的解决方案- 如果您必须使用GDI +，请在应用程序池的设置中增加MaxWorkerProcesses