图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
文章来源于领测软件测试网 https://www.ltesting.net/
