每个人都可以参与
如果我们让模拟线程尽可能快地发出请求，就是在模拟整个全域(甚至更多)的用户都在同一时间发出请求。我们假定服务器模型为单一的，因为这样便于理解;多服务器模型的工作方式是相同的，只是更快一些。系统将把请求排队，并且每次只处理一个。一旦有一个请求清除，线程会立即返回队列头部发出下一个请求。虽然这种事件顺序似乎说明我们处理的是一个稳定状态的系统，但我们实际上是在处理发散系统。它之所以看起来像稳定状态系统的惟一原因是，我们限制了发出请求的线程数目。正如前面所提到的，在发散系统中，每个后继用户的响应时间都要比前一个所经历的时间长。这意味着平均响应时间将不断地增长而没有限制。尽管如此，但是我们人为地限制了客户端的数目，因此平均响应时间将稳定在一个点上，该点取决于客户端数目与处理单个请求所花费时间的乘积。这里所说的这种系统中的响应时间包括花在队列中的时间，而且因为花在队列中的时间比预料的要少，所以我们又人为扩大了测量值。最终结果是您的测试限制了您确定系统的可伸缩性的能力。
如何修复
要修复压力测试，需要知道用户/线程发出请求的速度。所有用户的速度之和就转化为服务器接受请求的速度。一旦确定了这个值，就可以对工具发出请求的速度进行调整。下面的表列出了几个可以用来维持50个请求每秒(RPS)的值。从服务器的视角来看，工具需要每20ms提供一个请求。这种观点反映的是单个线程的情况。如果工具配置了两个线程，那么对于每个线程，都应该维持40ms的请求间时间间隔。表中还列出了使用5个线程和10个线程的情况下的时间间隔。
抉择
从理论上来说，这个表展示了如何使用1个、2个、5个、10个线程来实现所要求的维持50个RPS的目标。但是如果服务时间比请求间时间间隔长的话会怎么样呢?这种情况下驻留在服务器中的线程不能使下一个请求排入队列，工具也不能交付50RPS的预期负载。为了避免这种情况发生，需要在系统中构建一些空余时间(slack)。使用大量线程的方案对我们来说通常是不可行的，因为我们很有可能要受到可用的硬件数目和/或许可证数目(对于商业的负载测试工具来说)的限制。解决方法其实很常见，就是我们需要达到一种维持合适的请求间时间间隔与使用过多的(计算/许可)资源之间的平衡。我们要始终记住，如果测试工具使用的资源(不管是硬件、软件或是线程)很少，就会影响我们测试的有效性。
三思而后行
我们使用Apache JMeter来对随机的Web应用程序进行负载测试，以说明压力测试工具是如何影响测试结果的。除了要知道应用程序的入口点是Servlet，应用程序的功能以及如何实现的详细信息对于我们的讨论来说并不重要。
图1显示了在平均响应时间下增加线程数目的效果。其中粉红色的线是没有调整线程的情况。蓝色的线是在每两个线程之间添加了500ms的空余时间后的线程。从图中可以看出，两种情况的结果差别非常小。每种情况都清楚表明，随着系统的负载增加，响应时间也会增加。既然我们已经知道服务器的性能会随总体负载的增加而降低，这样的结果也就不奇怪了。我们只是在看图2所示的结果时才能看出存在的问题。
图1
文章来源于领测软件测试网 https://www.ltesting.net/
