提到的，在发散系统中，每个后继用户的响应时间都要比前一个所经历的时间长。这意味着平均响应时间将不断地增长而没有限制。尽管如此，但是我们人为地限制了客户端的数目，因此平均响应时间将稳定在一个点上，该点取决于客户端数目与处理单个请求所花费时间的乘积。这里所说的这种系统中的响应时间包括花在队列中的时间，而且因为花在队列中的时间比预料的要少，所以我们又人为扩大了测量值。最终结果是您的测试限制了您确定系统的可伸缩性的能力。
如何修复
要修复压力测试，需要知道用户/线程发出请求的速度。所有用户的速度之和就转化为服务器接受请求的速度。一旦确定了这个值，就可以对工具发出请求的速度进行调整。下面的表列出了几个可以用来维持50个请求每秒(RPS)的值。从服务器的视角来看，工具需要每20ms提供一个请求。这种观点反映的是单个线程的情况。如果工具配置了两个线程，那么对于每个线程，都应该维持40ms的请求间时间间隔。表中还列出了使用5个线程和10个线程的情况下的时间间隔。
|
线程数目 |
线程频率 |
请求间时间间隔(inter-request interval) |
|
1 |
50/sec |
20ms |
|
2 |
25/sec |
40ms |
|
5 |
10/sec |
100ms |
|
10 |
5/sec |
200ms |
抉择
从理论上来说，这个表展示了如何使用1个、2个、5个、10个线程来实现所要求的维持50个RPS的目标。但是如果服务时间比请求间时间间隔长的话会怎么样呢？这种情况下驻留在服务器中的线程不能使下一个请求排入队列，工具也不能交付50RPS的预期负载。为了避免这种情况发生，需要在系统中构建一些空余时间(slack)。使用大量线程
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
