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

Mar*_*fin 6 asp.net iis performance multithreading

我有简单的ASP.NET应用程序,它只使用ImageResizer调整图像大小,并且不执行任何其他操作.出于测试目的,我禁用了磁盘缓存,因此每次请求都会调整图像大小.

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

  • 单个工作进程,1个并发客户端:~200ms
  • 单个工作进程,10个并发客户端:~1200ms
  • 4个工作进程,10个并发客户端:~300ms

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

这里所讨论的,

Web园的设计只有一个原因 - 提供不受CPU约束但执行长时间运行请求的应用程序能够扩展并且不会耗尽工作进程中可用的所有线程.

这似乎不是我的情况.

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

我的配置:

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

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

Mar*_*fin 4

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

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

找到问题原因后,我尝试了这个解决方案。从 ASP.NET 应用程序引用 WPF 程序集可能不是最好的主意,但出于测试目的是可以的。

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

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

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

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

  • 如果可以的话,不要使用基于 GDI+ 的解决方案
  • 如果必须使用 GDI+,请增加应用程序池设置中的 MaxWorkerProcesses