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

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

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

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

如您所见,当我运行单个工作进程和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 RAM

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

解决方法

@ Ben的评论我找到了答案.

问题是ImageResizer基于GDI(如it’s site所述),其中包含锁(有关详细信息,请参阅this和this帖子).这就是为什么它在单个过程中运行得如此缓慢.

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

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

>单个工作进程,1个并发客户端：~90ms
>单个工作进程,10个并发客户端：~120ms
>单个工作进程,40个并发客户端：~190ms
>单个工作进程,60个并发客户端：~400ms
>单个工作进程,80个并发客户端：~630ms

如您所见,现在应用程序工作得更快.它也充分利用了高负载下几乎所有可用的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