图1显示了在平均响应时间下增加线程数目的效果。其中粉红色的线是没有调整线程的情况。蓝色的线是在每两个线程之间添加了500ms的空余时间后的线程。从图中可以看出，两种情况的结果差别非常小。每种情况都清楚表明，随着系统的负载增加，响应时间也会增加。既然我们已经知道服务器的性能会随总体负载的增加而降低，这样的结果也就不奇怪了。我们只是在看图2所示的结果时才能看出存在的问题。
图2显示维持稳定的请求速度的能力最初是受制于线程数目的。同样这也不能说明问题，因为有理由假定，在超出特定的线程数目阈值之前，不能维持合理的服务器负载。图2也显示，一旦超出了服务器处理请求的能力，线程的增加对工具向服务器发出请求的整体速度的影响就不明显了。另外一点是，这些“额外”的线程所造成的响应时间的增加确实暗示它们影响了系统的负载。
问题在于：为什么不增加服务器负载的线程看起来会降低服务器的性能？一个可能的答案就是，并不是线程降低了服务器的性能，而是服务器一结束对线程的服务，线程就被排队了。因为测量响应时间的计时器必须在将请求发送给服务器时启动，在收到响应时停止，所以响应时间必然包括线程在队列中等待服务的所有时间，再加上服务时间。因为线程一离开就进入系统，就造成了这样的情况：线程必须等待其他每个线程完成后才能被服务。在这种场景下，线程越多就会造成队列和响应时间越长。
利托氏定理告诉我们，这种系统是发散的，而由此可以得出结论：工具妨碍了确定真正的瓶颈（如果存在的话）的能力。
放慢速度，做得更多
利托氏定理包括两个部分：服务时间和频率。如果我们以工具的眼光来看世界，那么我们会发现我们不能控制服务时间。但是我们确实能控制频率。既然前面的工作说明我们进行得太快了（或者说在错误的方向上进行得太快了），而我们惟一能控制的就是频率，那么我们惟一能做的就是放慢速度。我们可以通过在每两个请求之间插入间歇来达到这个目的。这将会降低单个线程启动请求的速度。间歇会降低线程在队列中的时间，从而提供更符合现实的响应时间。
为了测试，我们将启动50个经过调整的每秒产生9个请求的线程。如果我们发现不能维持合理的请求速度，这些值还可以调整。使用响应时间来评价效果。最后要设置的是间歇时间。可以使用由先前运行得出的数据来帮助我们做出决定。
回到图1，我们可以看到，8到9个RPS会产生2到3秒的响应时间。利托氏定理告诉我们，我们需要足够的线程，以便在2到3秒的时间帧后就可以自由进入系统（假定可以提高平均响应时间）。因此平均的间歇时间大约是3秒。为了练习，我们将运行一系列的测试来探讨值的范围。
第一次测试使用2到2.5秒之间的一个随机选取的值。这个范围的值的平均间歇时间是3.5秒。可以利用这条信息计算请求的理论速度：用50（线程数目）除以3.5+2（目标响应时间的估测值）。得到的值是9.1RPS。第二次测试使用3到6秒之间的一个随机值。最终测试使用4到6之间的值。这些测试的结果如图3所示。
图3说明增加间歇的时间会使平均响应时间缩短。但是这条信息需要与图4所传达的信息相结合。在图4中，我们可以看到，当间歇时间增加到4-7秒时不能保持要求的向服务器发出请求的速度。我们可以通过添加更多的线程来增加负载，但是这一步中存在最小值，因为这些测试的确为我们提供了有效的配置。
这一系列的测试有助于将压力测试推进到一个更好的配置。我们的结论是：应该配置我们的测试工具，使其使用50个线程，每个线程的间歇时间为3到6秒。
结束语
在开始性能调优实践（或者为性能确定基准）之前，需要确认工具不会影响测试。配置良好的工具不会让我们测量不该测量的数据。不能交付适当的负载或会使我们测量偶然的响应时间的测试工具将会影响对应用程序进行性能调优的工作。要想知道是否发生了这种情况，关键是要度量工具以正常速度运行的效果。这种效果可以由工具满足或支持所要求的每秒的事务或请求数目的能力来确定。工具不应该立刻轮换线程（来发出下一个请求）。如果发生了这种情况，就需要降低工具的速度，以免人为地使服务器的容量溢出。通常需要试验几次以达到测试工具的适当的平衡配置。在测试的早期阶段，不要把重点放在响应时间（它会随着对应用程序调优的过程而改善）上，而是要放在配置好工具上。最后，不要害怕放慢速度，因为这样做可能有助于弄清楚到底是什么影响了应用程序的性能。
文章来源于领测软件测试网 https://www.ltesting.net/
