的方案对我们来说通常是不可行的，因为我们很有可能要受到可用的硬件数目和/或许可证数目（对于商业的负载测试工具来说）的限制。解决方法其实很常见，就是我们需要达到一种维持合适的请求间时间间隔与使用过多的（计算/许可）资源之间的平衡。我们要始终记住，如果测试工具使用的资源（不管是硬件、软件或是线程）很少，就会影响我们测试的有效性。
三思而后行
我们使用Apache JMeter来对随机的Web应用程序进行负载测试，以说明压力测试工具是如何影响测试结果的。除了要知道应用程序的入口点是Servlet，应用程序的功能以及如何实现的详细信息对于我们的讨论来说并不重要。
图1显示了在平均响应时间下增加线程数目的效果。其中粉红色的线是没有调整线程的情况。蓝色的线是在每两个线程之间添加了500ms的空余时间后的线程。从图中可以看出，两种情况的结果差别非常小。每种情况都清楚表明，随着系统的负载增加，响应时间也会增加。既然我们已经知道服务器的性能会随总体负载的增加而降低，这样的结果也就不奇怪了。我们只是在看图2所示的结果时才能看出存在的问题。
图2显示维持稳定的请求速度的能力最初是受制于线程数目的。同样这也不能说明问题，因为有理由假定，在超出特定的线程数目阈值之前，不能维持合理的服务器负载。图2也显示，一旦超出了服务器处理请求的能力，线程的增加对工具向服务器发出请求的整体速度的影响就不明显了。另外一点是，这些“额外” 的线程所造成的响应时间的增加确实暗示它们影响了系统的负载。
问题在于：为什么不增加服务器负载的线程看起来会降低服务器的性能？一个可能的答案就是，并不是线程降低了服务器的性能，而是服务器一结束对线程的服务，线程就被排队了。因为测量响应时间的计时器必须在将请求发送给服务器时启动，在收到响应时停止，所以响应时间必然包括线程在队列中等待服务的所有时间，再加上服务时间。因为线程一离开就进入系统，就造成了这样的情况：线程必须等待其他每个线程完成后才能被服务。在这种场景下，线程越多就会造成队列和响应时间越长。
利托氏定理告诉我们，这种系统是发散的，而由此可以得出结论：工具妨碍了确定真正的瓶颈（如果存在的话）的能力。
放慢速度，做得更多
文章来源于领测软件测试网 https://www.ltesting.net/
