IHttpHandler与HttpTaskAsyncHandler性能

Question

我们有一个We应用程序，它通过.NET IHttpHandler (称为proxy.ashx)路由许多请求，用于CORS和安全目的。一些资源加载速度快，另一些资源加载速度慢，因为这些资源所需的计算量很大。这是意料之中的。

在重负载期间，proxy.ashx会慢到爬行，所有资源都要花费很长时间才能加载。在这些峰值负载期间，如果您绕过代理并直接加载资源，它将立即加载，这意味着代理是瓶颈。

(即资源加载慢，而资源自己加载快)。

我有一个假设，即降低响应是因为IHttpHandler是同步编码的，当太多长时间运行的请求处于活动状态时，IIS请求线程都很忙。我创建了一个快速的A/B测试应用程序来验证我的假设，我的测试结果表明事实并非如此。

这篇文章是我理解请求线程池的基础。

在.NET服务器上，维护用于服务ASP.NET请求的线程池。当请求到达时，将从池中分派一个线程来处理该请求。如果请求是同步处理的，则在处理请求时，处理请求的线程将被阻塞，并且该线程无法处理另一个请求。..。 但是，在异步调用期间，当服务器等待第一个请求完成时，不会阻止服务器响应其他请求。因此，当有许多请求调用长期运行的操作时，异步请求会阻止请求队列.

在下面的示例中，理论上，同步处理程序应该在某个阈值之后占据请求线程，从而防止更多的新请求启动。异步处理程序应该允许更多的请求排队，因为每个请求几乎都会在等待Task.Delay时立即将请求线程返回到线程池，从而允许请求线程在上一个请求仍在等待时处理新请求。

同步HttpHandler

<%@ WebHandler Language="C#" Class="SyncHandler" %>
using System.Web;
using System.Threading;
public class SyncHandler : IHttpHandler
{
    public void ProcessRequest(HttpContext context)
    {
        //BLOCKING artifical pause to simulate network activity
        Thread.Sleep(300);
        var Response = context.Response;
        Response.Write("sync response");
    }
    public bool IsReusable { get { return true; } }
}

异步处理器

<%@ WebHandler Language="C#" Class="AsyncHandler" %>
using System.Web;
using System.Threading.Tasks;

public class AsyncHandler : HttpTaskAsyncHandler
{
    public override async Task ProcessRequestAsync(HttpContext context)
    {
        //NON-BLOCKING artificial pause to simulate network activity
        await Task.Delay(300);
        var Response = context.Response;
        Response.Write("async response");
    }
    public override bool IsReusable { get { return true; } }
}

Benchmarking

我使用apache实用工具运行了一些基准测试。下面是我使用的命令(显然，更改下面结果的数字)。

ab -n 1000 -c 10 http://localhost/AsyncProxyTest/Sync.ashx

ab -n 1000 -c 10 http://localhost/AsyncProxyTest/Async.ashx

结果

1 000次请求，每次10次

• 同步: 30.10次请求/秒
• 异步: 32.05请求/秒

10 000次请求，每次100次

• 同步: 33.02请求/秒
• 异步: 32.05请求/秒

10 000次请求，每次1 000次

• 同步: 32.55次请求/秒
• 异步: 32.05请求/秒

正如您所看到的，同步与异步似乎几乎没有任何效果(至少不足以使其值得切换)。

我的问题是:我是否在测试中搞砸了一些不能准确建模这个概念的东西？

Answer 1

IIS的桌面版本有一个限制，即每次将并发请求限制为10个(请参见这个职位)。此限制不存在于IIS Express中，也不存在于Windows服务器上的IIS中。

测试没有什么问题，它们只需要在不受限制的web服务器上运行。我在Windows上使用IIS重新运行了这些测试，我的发现与我最初的假设完全一样。

这是再次的结果。(注意:这些结果来自一个非常活跃的开发服务器，因此可能会有一些变化)

1 000次请求，每次10次

(这些结果是相同的，因为我们没有超过请求限制)

• 同步: 31.88次请求/秒
• 异步: 29.13请求/秒

10 000次请求，每次100次

• 同步: 68.53次请求/秒
• 异步: 310.66次请求/秒

10 000次请求，每次1 000次

• 同步: 55.09请求/秒
• 异步: 669.41次请求/秒

我捕获的另一个指标是运行的并发请求的最大数量。这就是我如何发现我的本地机器的限制为10。在Windows服务器上再次运行测试之后，同步的最大值为48个并发请求。对于异步，它是301，这意味着异步/等待在处理非阻塞调用时肯定会产生更高的吞吐量。