如何调整压力测试工具[2] 压力测试工具
如何修复
要修复压力测试，需要知道用户/线程发出请求的速度。所有用户的速度之和就转化为服务器接受请求的速度。一旦确定了这个值，就可以对工具发出请求的速度进行调整。下面的表列出了几个可以用来维持50个请求每秒(RPS)的值。从服务器的视角来看，工具需要每20ms提供一个请求。这种观点反映的是单个线程的情况。如果工具配置了两个线程，那么对于每个线程，都应该维持40ms的请求间时间间隔。表中还列出了使用5个线程和10个线程的情况下的时间间隔。
抉择
从理论上来说，这个表展示了如何使用1个、2个、5个、10个线程来实现所要求的维持50个RPS的目标。但是如果服务时间比请求间时间间隔长的话会怎么样呢?这种情况下驻留在服务器中的线程不能使下一个请求排入队列，工具也不能交付50RPS的预期负载。为了避免这种情况发生，需要在系统中构建一些空余时间(slack)。使用大量线程的方案对我们来说通常是不可行的，因为我们很有可能要受到可用的硬件数目和/或许可证数目(对于商业的负载测试工具来说)的限制。解决方法其实很常见，就是我们需要达到一种维持合适的请求间时间间隔与使用过多的(计算/许可)资源之间的平衡。我们要始终记住，如果测试工具使用的资源(不管是硬件、软件或是线程)很少，就会影响我们测试的有效性。
三思而后行 软件测试
我们使用Apache JMeter来对随机的Web应用程序进行负载测试，以说明压力测试工具是如何影响测试结果的。除了要知道应用程序的入口点是Servlet，应用程序的功能以及如何实现的详细信息对于我们的讨论来说并不重要。
图1显示了在平均响应时间下增加线程数目的效果。其中粉红色的线是没有调整线程的情况。蓝色的线是在每两个线程之间添加了500ms的空余时间后的线程。从图中可以看出，两种情况的结果差别非常小。每种情况都清楚表明，随着系统的负载增加，响应时间也会增加。既然我们已经知道服务器的性能会随总体负载的增加而降低，这样的结果也就不奇怪了。我们只是在看图2所示的结果时才能看出存在的问题。
图1
图2显示维持稳定的请求速度的能力最初是受制于线程数目的。同样这也不能说明问题，因为有理由假定，在超出特定的线程数目阈值之前，不能维持合理的服务器负载。图2也显示，一旦超出了服务器处理请求的能力，线程的增加对工具向服务器发出请求的整体速度的影响就不明显了。另外一点是，这些“额外”的线程所造成的响应时间的增加确实暗示它们影响了系统的负载。
图2
文章来源于领测软件测试网 https://www.ltesting.net/
