.Net 4.5 中的异步 HttpClient 对于密集负载应用程序来说是一个糟糕的选择吗？

Posted 2023-03-30

【中文标题】.Net 4.5 中的异步 HttpClient 对于密集负载应用程序来说是一个糟糕的选择吗？

【英文标题】：Is async HttpClient from .Net 4.5 a bad choice for intensive load applications?

【发布时间】：2013-04-24 14:03:04

【问题描述】：

我最近创建了一个简单的应用程序，用于测试可以异步方式与经典多线程方法生成的 HTTP 调用吞吐量。

该应用程序能够执行预定义数量的 HTTP 调用，并在最后显示执行它们所需的总时间。在我的测试过程中，所有 HTTP 调用都是对我的本地 IIS 服务器进行的，它们检索到一个小文本文件（大小为 12 字节）。

下面列出了异步实现代码中最重要的部分：

public async void TestAsync()

    this.TestInit();
    HttpClient httpClient = new HttpClient();

    for (int i = 0; i < NUMBER_OF_REQUESTS; i++)
    
        ProcessUrlAsync(httpClient);
    


private async void ProcessUrlAsync(HttpClient httpClient)

    HttpResponseMessage httpResponse = null;

    try
    
        Task<HttpResponseMessage> getTask = httpClient.GetAsync(URL);
        httpResponse = await getTask;

        Interlocked.Increment(ref _successfulCalls);
    
    catch (Exception ex)
    
        Interlocked.Increment(ref _failedCalls);
    
    finally
     
        if(httpResponse != null) httpResponse.Dispose();
    

    lock (_syncLock)
    
        _itemsLeft--;
        if (_itemsLeft == 0)
        
            _utcEndTime = DateTime.UtcNow;
            this.DisplayTestResults();
        
    

下面列出了多线程实现中最重要的部分：

public void TestParallel2()

    this.TestInit();
    ServicePointManager.DefaultConnectionLimit = 100;

    for (int i = 0; i < NUMBER_OF_REQUESTS; i++)
    
        Task.Run(() =>
        
            try
            
                this.PerformWebRequestGet();
                Interlocked.Increment(ref _successfulCalls);
            
            catch (Exception ex)
            
                Interlocked.Increment(ref _failedCalls);
            

            lock (_syncLock)
            
                _itemsLeft--;
                if (_itemsLeft == 0)
                
                    _utcEndTime = DateTime.UtcNow;
                    this.DisplayTestResults();
                
            
        );
    


private void PerformWebRequestGet()
 
    HttpWebRequest request = null;
    HttpWebResponse response = null;

    try
    
        request = (HttpWebRequest)WebRequest.Create(URL);
        request.Method = "GET";
        request.KeepAlive = true;
        response = (HttpWebResponse)request.GetResponse();
    
    finally
    
        if (response != null) response.Close();
    

运行测试显示多线程版本更快。完成 10k 个请求大约需要 0.6 秒，而对于相同的负载量，异步请求大约需要 2 秒。这有点令人惊讶，因为我希望异步更快。也许是因为我的 HTTP 调用非常快。在实际场景中，服务器应该执行更有意义的操作并且还应该存在一些网络延迟，结果可能会相反。

然而，我真正关心的是当负载增加时 HttpClient 的行为方式。由于传送 10k 条消息大约需要 2 秒，我认为传送 10 倍的消息需要大约 20 秒，但运行测试表明传送 100k 条消息需要大约 50 秒。此外，传递 200k 条消息通常需要 2 分钟以上，而且通常有几千条（3-4k）条消息会失败，但有以下例外：

无法对套接字执行操作，因为系统缺少足够的缓冲区空间或队列已满。

我检查了 IIS 日志和失败的操作从未到达服务器。他们在客户内部失败了。我在 Windows 7 机器上运行测试，临时端口的默认范围为 49152 到 65535。运行 netstat 显示测试期间使用了大约 5-6k 端口，因此理论上应该有更多可用端口。如果缺少端口确实是异常的原因，则意味着 netstat 没有正确报告情况，或者 HttClient 仅使用了最大数量的端口，之后它开始抛出异常。

相比之下，生成 HTTP 调用的多线程方法表现得非常可预测。我花了大约 0.6 秒处理 10k 条消息，大约 5.5 秒处理 100k 条消息，正如预期的那样，处理 100 万条消息大约需要 55 秒。没有一条消息失败。此外，在运行时，它从未使用超过 55 MB 的 RAM（根据 Windows 任务管理器）。异步发送消息时使用的内存与负载成比例增长。在 200k 消息测试期间，它使用了大约 500 MB 的 RAM。

我认为上述结果有两个主要原因。第一个是 HttpClient 在与服务器创建新连接时似乎非常贪婪。 netstat 报告的大量使用端口意味着它可能不会从 HTTP keep-alive 中受益。

第二个是HttpClient似乎没有节流机制。事实上，这似乎是与异步操作相关的普遍问题。如果您需要执行大量操作，它们将立即启动，然后它们的延续将在可用时执行。理论上这应该没问题，因为在异步操作中，负载在外部系统上，但正如上面所证明的，情况并非完全如此。一次启动大量请求会增加内存使用量并减慢整个执行速度。

通过使用简单但原始的延迟机制限制异步请求的最大数量，我设法在内存和执行时间方面获得了更好的结果：

public async void TestAsyncWithDelay()

    this.TestInit();
    HttpClient httpClient = new HttpClient();

    for (int i = 0; i < NUMBER_OF_REQUESTS; i++)
    
        if (_activeRequestsCount >= MAX_CONCURENT_REQUESTS)
            await Task.Delay(DELAY_TIME);

        ProcessUrlAsyncWithReqCount(httpClient);
    

如果 HttpClient 包含一个限制并发请求数量的机制，那将非常有用。使用 Task 类（基于 .Net 线程池）时，通过限制并发线程数自动实现节流。

为了全面了解，我还创建了一个基于 HttpWebRequest 而不是 HttpClient 的异步测试版本，并设法获得了更好的结果。首先，它允许设置并发连接数的限制（使用 ServicePointManager.DefaultConnectionLimit 或通过配置），这意味着它永远不会耗尽端口，也永远不会在任何请求上失败（HttpClient，默认情况下，基于 HttpWebRequest ，但似乎忽略了连接限制设置）。

异步 ​​HttpWebRequest 方法仍然比多线程方法慢 50-60%，但它是可预测且可靠的。唯一的缺点是它在大负载下使用了大量内存。例如，它需要大约 1.6 GB 来发送 100 万个请求。通过限制并发请求的数量（就像我在上面对 HttpClient 所做的那样），我设法将使用的内存减少到仅 20 MB，并获得比多线程方法慢 10% 的执行时间。

在这个冗长的介绍之后，我的问题是：.Net 4.5 中的 HttpClient 类对于密集负载应用程序来说是不是一个糟糕的选择？有什么方法可以限制它，这应该可以解决我提到的问题吗？ HttpWebRequest 的异步风格怎么样？

更新（感谢@Stephen Cleary）

事实证明，HttpClient 与 HttpWebRequest（默认基于）一样，可以通过 ServicePointManager.DefaultConnectionLimit 限制同一主机上的并发连接数。奇怪的是，根据MSDN，连接限制的默认值为2。我还使用调试器检查了这一点，它指出确实2是默认值。但是，似乎除非显式为 ServicePointManager.DefaultConnectionLimit 设置一个值，否则默认值将被忽略。由于我在 HttpClient 测试期间没有明确设置它的值，我认为它被忽略了。

在将 ServicePointManager.DefaultConnectionLimit 设置为 100 之后，HttpClient 变得可靠且可预测（netstat 确认仅使用了 100 个端口）。它仍然比异步 HttpWebRequest 慢（大约 40%），但奇怪的是，它使用的内存更少。对于涉及 100 万个请求的测试，它使用了最大 550 MB，而异步 HttpWebRequest 使用了 1.6 GB。

因此，虽然 HttpClient 与 ServicePointManager.DefaultConnectionLimit 组合似乎确保了可靠性（至少对于所有调用都针对同一主机进行的情况），但它的性能似乎仍因缺乏适当的节流机制。将并发请求数限制为可配置值并将其余请求放入队列中的东西将使其更适合高可扩展性场景。

【问题讨论】：

HttpClient 应该尊重ServicePointManager.DefaultConnectionLimit。

您的观察似乎值得研究。不过有一件事困扰着我：我认为一次发出数千个异步 IO 是非常人为的。我永远不会在生产中这样做。您是异步的这一事实并不意味着您可以疯狂地消耗各种资源。 （微软的官方样本在这方面也有点误导。）

不过，不要因时间延迟而节流。在您凭经验确定的固定并发级别上进行节流。一个简单的解决方案是 SemaphoreSlim.WaitAsync，尽管它也不适合任意大量的任务。

@svick，感谢您的建议。我对手动实现限制/并发限制的机制不感兴趣。如前所述，我的问题中包含的实现仅用于测试和验证理论。我不想改进它，因为它不会投入生产。我感兴趣的是 .Net 框架是否提供了一种内置机制来限制异步 IO 操作的并发性（包括 HttpClient）。

【参考方案1】：

除了问题中提到的测试之外，我最近创建了一些新的测试，涉及更少的 HTTP 调用（5000 次与之前的 100 万次相比），但请求的执行时间要长得多（500 毫秒与之前的大约 1 毫秒相比）。两个测试应用程序，同步多线程应用程序（基于 HttpWebRequest）和异步 I/O 应用程序（基于 HTTP 客户端）产生了相似的结果：使用大约 3% 的 CPU 和 30 MB 内存执行大约 10 秒。两个测试器之间的唯一区别是多线程的一个使用 310 个线程来执行，而异步的只有 22 个。因此，在一个结合了 I/O 绑定和 CPU 绑定操作的应用程序中，异步版本会产生更好的结果因为执行 CPU 操作的线程会有更多可用的 CPU 时间，而这些线程实际上需要它（等待 I/O 操作完成的线程只是在浪费）。

作为我的测试的结论，在处理非常快速的请求时，异步 HTTP 调用并不是最佳选择。其背后的原因是，当运行包含异步 I/O 调用的任务时，一旦进行异步调用，启动任务的线程就会退出，并将任务的其余部分注册为回调。然后，当 I/O 操作完成时，回调将排队等待在第一个可用线程上执行。所有这些都会产生开销，这使得快速 I/O 操作在启动它们的线程上执行时更加高效。

在处理长或可能长的 I/O 操作时，异步 HTTP 调用是一个不错的选择，因为它不会让任何线程忙于等待 I/O 操作完成。这减少了应用程序使用的线程总数，允许 CPU 绑定操作花费更多 CPU 时间。此外，在只分配有限数量线程的应用程序上（如 Web 应用程序的情况），异步 I/O 可防止线程池线程耗尽，如果同步执行 I/O 调用，可能会发生这种情况。

因此，异步 HttpClient 不是密集负载应用程序的瓶颈。只是就其本质而言，它不太适合非常快速的 HTTP 请求，而是非常适合长或可能长的请求，尤其是在只有有限数量可用线程的应用程序中。此外，通过 ServicePointManager.DefaultConnectionLimit 限制并发性是一个很好的做法，其值足够高以确保良好的并行度，但又足够低以防止临时端口耗尽。你可以找到更多关于这个问题here的测试和结论的细节。

【讨论】：

“非常快”有多快？ 1毫秒？ 100 毫秒？ 1000 毫秒？

我正在使用类似于您的“异步”方法在 Windows 上部署的 WebLogic Web 服务器上重放负载，但我很快就遇到了短暂的端口耗尽问题。我还没有触及 ServicePointManager.DefaultConnectionLimit，我正在处理和重新创建每个请求的所有内容（HttpClient 和响应）。您知道是什么原因导致连接保持打开状态并耗尽端口吗？

@TimP。对于我的测试，如上所述，“非常快”是只需要 1 毫秒即可完成的请求。在现实世界中，这始终是主观的。在我看来，相当于本地网络数据库上的小查询的东西可以被认为是快的，而相当于互联网上的 API 调用的东西可以被认为是慢的或可能很慢。

@Iravanchi，在“异步”方法中，请求发送和响应处理是分开执行的。如果您有很多电话，所有的请求都将被发送得非常快，并在它们到达时处理响应。由于您只能在响应到达后处理连接，因此大量并发连接会累积并耗尽您的临时端口。您应该使用 ServicePointManager.DefaultConnectionLimit 限制最大并发连接数。

@FlorinDumitrescu，我还要补充一点，网络调用本质上是不可预测的。 90% 的时间在 10 毫秒内运行的事情可能会在网络资源拥塞或其他 10% 的时间不可用时导致阻塞问题。

【参考方案2】：

要考虑的可能会影响您的结果的一件事是，使用 HttpWebRequest 您不会获得 ResponseStream 并使用该流。使用 HttpClient，默认情况下它将网络流复制到内存流中。为了以与当前使用 HttpWebRquest 相同的方式使用 HttpClient，您需要这样做

var requestMessage = new HttpRequestMessage() RequestUri = URL;
Task<HttpResponseMessage> getTask = httpClient.SendAsync(requestMessage, HttpCompletionOption.ResponseHeadersRead);

另一件事是我不确定真正的区别是什么，从线程的角度来看，你实际上是在测试。如果您深入研究 HttpClientHandler ，它只会执行 Task.Factory.StartNew 以执行异步请求。线程行为被委托给同步上下文，方式与您的 HttpWebRequest 示例完全相同。

毫无疑问，HttpClient 会增加一些开销，因为默认情况下它使用 HttpWebRequest 作为其传输库。因此，在使用 HttpClientHandler 时，您将始终能够直接通过 HttpWebRequest 获得更好的性能。 HttpClient 带来的好处在于标准类，如 HttpResponseMessage、HttpRequestMessage、HttpContent 和所有强类型标头。它本身并不是性能优化。

【讨论】：

（旧答案，但是）HttpClient 似乎很容易使用，我认为异步是要走的路，但似乎有很多“但是和如果”。也许应该重写HttpClient，以便使用起来更直观？或者文档真的在强调如何最有效地使用它的重要事项？

@mortb, Flurl.Http flurl.io 是一个更直观的使用 HttpClient 的包装器

@MichaelFreidgeim：谢谢，虽然我现在已经学会使用 HttpClient...

【参考方案3】：

虽然这并没有直接回答 OP 问题的“异步”部分，但它解决了他正在使用的实现中的一个错误。

如果您希望您的应用程序可扩展，请避免使用基于实例的 HttpClients。差异是巨大的！根据负载，您将看到非常不同的性能数字。 HttpClient 旨在跨请求重用。编写它的 BCL 团队的人证实了这一点。

我最近的一个项目是帮助一家非常大型的知名在线计算机零售商扩展一些新系统的黑色星期五/假日流量。我们在使用 HttpClient 时遇到了一些性能问题。由于它实现了IDisposable，因此开发人员通过创建一个实例并将其放置在using() 语句中来完成您通常会做的事情。一旦我们开始对应用程序进行负载测试，服务器就会崩溃——是的，服务器不仅仅是应用程序。原因是 HttpClient 的每个实例都会在服务器上打开一个 I/O 完成端口。由于 GC 的非确定性最终确定以及您正在使用跨越多个 OSI layers 的计算机资源这一事实，关闭网络端口可能需要一段时间。事实上，Windows 操作系统本身最多可能需要 20 秒才能关闭一个端口（根据 Microsoft）。我们打开端口的速度比关闭端口的速度要快——服务器端口耗尽导致 CPU 达到 100%。我的解决方法是将 HttpClient 更改为解决问题的静态实例。是的，它是一种一次性资源，但性能差异远远超过了任何开销。我鼓励您进行一些负载测试以了解您的应用的行为方式。

也在下面的链接中回答：

What is the overhead of creating a new HttpClient per call in a WebAPI client?

https://www.asp.net/web-api/overview/advanced/calling-a-web-api-from-a-net-client

【讨论】：

我发现在客户端创建 TCP 端口耗尽的问题完全相同。解决方案是在进行迭代调用的情况下长时间租用 HttpClient 实例，而不是为每个调用创建和处置。我得出的结论是“仅仅因为它实现了 Dispose，这并不意味着 Dispose 它便宜”。

所以如果 HttpClient 是静态的，并且我需要更改下一个请求的标头，那么这对第一个请求有什么影响？更改 HttpClient 是否有任何危害，因为它是静态的 - 例如发出 HttpClient.DefaultRequestHeaders.Accept.Clear(); ?例如，如果我有用户通过令牌进行身份验证，则需要将这些令牌添加为 API 请求的标头，其中是不同的令牌。将 HttpClient 设为静态，然后在 HttpClient 上更改此标头会产生不利影响吗？

如果您需要使用 HttpClient 实例成员，例如 headers/cookies 等，则不应使用静态 HttpClient。否则，您的实例数据（标头、cookie）对于每个请求都是相同的——当然不是您想要的。

既然是这种情况......你将如何防止你在帖子中描述的内容 - 防止负载？负载均衡器并向其投放更多服务器？

@crizzwald - 在我的帖子中，我注意到使用的解决方案。使用 HttpClient 的静态实例。如果您需要在 HttpClient 上使用标头/cookies，我会考虑使用替代方法。