IIS 8.5单工作进程与Web Garden性能 [英] IIS 8.5 single worker process vs Web Garden performance

问题描述

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

I have simple ASP.NET application that just resizes images with ImageResizer and does nothing else. For testing purposes I disabled disk caching, so images are resized on every request.

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

When I test performance of the app with JMeter I get the following average response times:

• 单个工作进程，1个并发客户端：~200ms


• 单个工作进程，10个并发客户端：〜 1200毫秒


• 4个工作进程，10个并发客户端：~300毫秒

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

As you can see, when I run single worker process and 10 concurrent clients, response time increases dramatically despite of available hardware resources: CPU usage during performance test is ~30%, memory usage is ~150MB.

如所讨论的那样这里，

网络花园是出于一个原因而设计的 - 提供不受CPU约束的应用程序
但是执行很久运行请求能力
来扩展并且不会耗尽工作进程中可用的所有线程。

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.

这看起来不像我的情况。

This is not looking as my case.

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

So, I don't understand why I get such result. What I expect is that even single worker process would provide acceptable response time until it reaches resources limits. And 10 concurrent clients are defenitely not a heavy load. Can somebody explain to me, where am I wrong?

我的配置：

• Windows Server 2012 R2


• IIS 8.5，包含所有默认设置（MaxWorkerThreads除外）


• 四核i3 3.4GHz CPU


• 16 GB RAM

• Windows Server 2012 R2
• IIS 8.5 with all default settings (except MaxWorkerThreads)
• quad-core i3 3.4GHz CPU
• 16 GB RAM

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

My application is just empty ASP.NET MVC application with ImageResizer, added as in this instruction (option 3 - Manual Installation) and with DiskCache plugin disabled in Web.config

推荐答案

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

I found an answer thanks to @Ben's comment.

问题是ImageResizer是基于GDI +（如它的网站所述），其中包含锁（参见这个和这个帖子了解详情）。这就是为什么它在单个过程中工作得那么慢的原因。

The problem is ImageResizer is based on GDI+ (as stated on it's site), which contains locks inside (see this and this posts for details). This is why it works so slowly in single process.

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

After finding the cause of problem I tried this solution. Referencing WPF assemblies from ASP.NET application is, probably, not a best idea, but it's ok for testing purposes.

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

Now I get the following results when I perform the same performance testing as in question:

• 单个工作进程，1个并发客户端：~90ms


• 单个工作进程，10个并发客户端：~120ms


• 单个工作进程， 40个并发客户端：~190ms


• 单个工作进程，60个并发客户端：~400ms


• 单个工作进程，80个并发客户端：~630ms

• single worker process, 1 concurrent client: ~90ms
• single worker process, 10 concurrent clients: ~120ms
• single worker process, 40 concurrent clients: ~190ms
• single worker process, 60 concurrent clients: ~400ms
• single worker process, 80 concurrent clients: ~630ms

如您所见，现在应用程序运行得更快。它也可以在高负载下使用几乎所有可用的CPU资源，正如我最初预期的那样。

As you can see, now application works much faster. Also it utilizes almost all available CPU resources under high load, as I expected initially.

因此，如果你在ASP.NET中处理图像申请：

So, if you process images in your ASP.NET application:

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


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

这篇关于IIS 8.5单工作进程与Web Garden性能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！