小编Chr*_*lid的帖子

我们有一个使用 IIS 中托管的 ServiceStack 实现的 API。在对 API 执行负载测试时，我们发现响应时间很好，但是一旦我们达到每台服务器大约 3,500 个并发用户，它们就会迅速恶化。我们有两台服务器，当有 7,000 名用户访问它们时，所有端点的平均响应时间都低于 500 毫秒。这些盒子在负载平衡器后面，所以我们每台服务器有 3,500 个并发。然而，一旦我们增加了总并发用户数，我们就会看到响应时间显着增加。将每台服务器的并发用户数增加到 5,000，我们每个端点的平均响应时间约为 7 秒。

服务器上的内存和 CPU 都非常低，而响应时间很好，而且响应时间很短。在 10,000 个并发用户的峰值时，CPU 平均略低于 50%，RAM 位于 3-4 GB 左右（共 16 个）。这让我们认为我们在某处达到了某种限制。下面的屏幕截图显示了在总共 10,000 个并发用户的负载测试期间 perfmon 中的一些关键计数器。突出显示的计数器是请求数/秒。在屏幕截图的右侧，您可以看到每秒请求数图表变得非常不稳定。这是响应时间缓慢的主要指标。一旦我们看到这种模式，我们就会注意到负载测试中的响应时间很慢。

我们如何解决这个性能问题？我们正在尝试确定这是编码问题还是配置问题。web.config 或 IIS 中是否有任何设置可以解释这种行为？应用程序池运行 .NET v4.0，IIS 版本为 7.5。我们对默认设置所做的唯一更改是将应用程序池队列长度值从 1,000 更新为 5,000。我们还在 Aspnet.config 文件中添加了以下配置设置：

<system.web>
    <applicationPool 
        maxConcurrentRequestsPerCPU="5000"
        maxConcurrentThreadsPerCPU="0" 
        requestQueueLimit="5000" />
</system.web>

更多细节：

API 的目的是组合来自各种外部来源的数据并以 JSON 形式返回。它目前正在使用 InMemory 缓存实现来缓存数据层的各个外部调用。对资源的第一个请求将获取所需的所有数据，对同一资源的任何后续请求都将从缓存中获取结果。我们有一个“缓存运行器”，它作为一个后台进程来实现，它以特定的时间间隔更新缓存中的信息。我们在从外部资源获取数据的代码周围添加了锁定。我们还实现了以异步方式从外部源获取数据的服务，因此端点应该只与最慢的外部调用一样慢（当然，除非我们在缓存中有数据）。这是使用 System.Threading.Tasks.Task 类完成的。我们是否会遇到进程可用线程数的限制？