为什么我们的响应时间突然激增?
我们有一个使用IIS托管的ServiceStack来实现的API。在执行API的负载测试时,我们发现响应时间不错,但是一旦我们达到每台服务器约3500个并发用户,响应时间就会迅速恶化。我们有两台服务器,当有7,000个用户访问时,所有端点的平均响应时间都在500毫秒以下。这些盒子位于负载均衡器的后面,因此每台服务器可获得3500个并发。但是,一旦我们增加了并发用户总数,响应时间就会大大增加。将并发用户增加到每台服务器5,000,可以使我们每个端点的平均响应时间约为7秒。 服务器上的内存和CPU都非常低,而响应时间很好,而且响应时间变慢了。在有10,000个并发用户的高峰时,CPU平均不到50%,而RAM位于16中的3-4 GB左右。这使我们认为我们正在达到某种极限。下面的屏幕快照显示了在负载测试过程中,总共有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类完成的。我们可以在进程可用线程数方面达到限制吗?