IIS 8.5单人工作进程vs Web花园性能
我有一个简单的ASP.NET应用程序，它只是用ImageResizer调整图像的大小，并且什么也不做。出于测试目的，我禁用了磁盘缓存，因此图像在每个请求上都调整大小。IIS 8.5单人工作进程vs Web花园性能
当我测试应用程序的性能与JMeter的，我得到以下的平均响应时间：
- 单一的工作进程，1个并发客户端：〜200ms的
- 单一的工作进程，10个并发客户端：〜1200ms
- 4个工作进程，10个并发客户端：〜300ms的
正如你可以看到，当我运行一个工作进程和10个并发客户端，响应时间增加博士尽管有可用的硬件资源，但仍然具有一定的性能：性能测试期间的CPU使用率约为30％，内存使用量约为150MB。
正如所讨论的here，
Web园是专为一个单一的原因 - 提供应用 不在CPU绑定的，但执行长时间运行的请求，规模和用不完中所有可用的线程的能力 工作进程。
这不是我的情况。
所以，我不明白为什么我会得到这样的结果。我期望的是，即使是单一的工作人员流程，也能提供可接受的响应时间，直到达到资源限制。而10个并发客户肯定不是一个沉重的负载。有人可以向我解释，我错在哪里？
我的配置：
- 的Windows Server 2012 R2
- IIS 8.5默认的设置（除MaxWorkerThreads）
- 四核酷睿i3 3.4GHz的CPU
- 16 GB RAM
我的应用程序只是空的ASP.NET MVC应用程序与ImageResizer，添加在this instruction（选项3 - 手动I安装）并且在Web.config中禁用了DiskCache插件
由于@ Ben的评论，我找到了答案。
问题是ImageResizer基于GDI +（如在it's site上所述），其中包含锁（请参阅this和this帖子以了解详细信息）。这就是为什么它在单一过程中如此缓慢的原因。
找到问题原因后我试了this solution。从ASP.NET应用程序引用WPF程序集可能不是一个好主意，但可以用于测试目的。
现在，我得到下面的结果，当我执行相同的性能测试中的问题：
- 单一的工作进程，1个并发客户端：〜90个毫秒
- 单一的工作进程，10个并发客户端：〜120毫秒
- 单个工作过程中，40个并发的客户端：〜190ms
- 单个工作过程中，60级并发的客户端：〜400个毫秒
- 单个工作过程中，80级并发的客户端：〜630ms
正如你可以看到，现在应用程序的工作要快得多。同样，它在高负载下利用几乎所有可用的CPU资源，正如我最初所预期的那样。
所以，如果你在你的ASP.NET应用程序中处理图像：
- 不使用GDI +基础的解决方案，如果你能
- ，如果你必须使用GDI +，增加广告应用程式MaxWorkerProcesses池的设置
只需根据您提供的，并且无需了解任何ImageResizer这些数字，它看起来像ImageResizer运行在一个单一的THR调整操作ead，也许是STA？如果它基于不支持多线程的COM组件，则这种（推测）可能是这种情况。 – Ben