在我们的生产环境中,我们已经开始体验到缓慢的WCF调用(入站)。我们过去能够在60-80ms内发送响应,但现在有时需要500-800ms甚至更长时间。
我开始在非生产环境中进行测试,使用JMeter模拟实时流量并测量响应时间。创建了JMeter测试计划,以便它以与我们的实际环境中大致相同的权重到达我们的不同端点。
现在,我在4个不同的端点上使用了9种不同的方法,有些是RESTful,有些是SOAP。
当我将每个线程组设置为一个线程(总共9个线程/用户)并开始一个固定持续时间为30秒的测试时,我会得到平均响应时间。45ms。在30秒内,我命中端点500次。
测试设置了恒定的吞吐量计时器,因此增加线程数量将保持相同的吞吐量。
当我将每个线程组的线程数增加到10个时(现在总共有90个线程),响应时间会急剧增加到平均水平。大约140ms仍然在30秒内访问端点大约500次,这告诉我问题/瓶颈与我们的服务器上的并行性有关。但我似乎不知道该去哪里找。
如果任何人对这个问题有一些意见,我将非常感谢,有没有对这种行为的解释,或者我必须检查我们的WCF端点的配置,IIS是否可以有一些相关的设置或其他任何东西?
我们的应用程序在windows 2012 R2服务器上的IIS8.5下运行,并使用.NET 4.5
提前感谢
发布于 2017-08-19 22:57:22
你的问题有很多原因:
并发sql queries
的代码中的IIS
没有更多的元素是不可能猜测的。
https://stackoverflow.com/questions/30345465
复制相似问题