如何调整电子商务网站的压力测试工具

阿七

如何调整压力测试工具
您是否曾经不得不对应用程序进行压力测试，而最后却发现不明白结果表明什么意义？也许问题不是出在应用程序上。也许问题出在配置压力测试工具的方式上。如果您曾经经历过这种情况，或者正要进行压力测试，您就需要考虑以下几个方面。
        如何进行测试？
        　　我经常遇到一些开发团队，他们收到诸如“客户端将每小时处理20个客户”此类的性能需求。团队就试图把该需求转化为某种测试。执行这种测试的常见方法就是以死循环的形式对服务器进行反复请求，然后静观其效。通常事情进行得不是很顺利，这就是为什么随后我会作为一个性能专业化方面的顾问“遇见他们”的原因。通常我问的第一个问题是：“您是如何进行测试的？”一般来说，答案会是：“我们将请求置于循环中，然后计算服务器可以处理的请求的数目。”正是这种回答使我明白首先要做的就是调整测试工具本身。
        　　如果您不明白上述测试有什么问题，不要担心——有很多人和您一样。进行一次切实可行的压力测试并不像乍看之下那么简单。遇到的问题可能非常微妙，而且通常只有采用不那么简单的方法来理清情况才能看清问题。但是这并不是让您目光呆滞地深入研究马尔可夫链(Markov chains)、状态改变模型、排队理论、概率分布等等，让我们以一种不那么乏味的、更通俗易懂的方式来说明如何解决这个在许多压力测试中出现的常见问题。
        测试方式将影响测试
        　　我们首先要明白的是，虽然测试通常都是从客户端活动的角度定义的，但是它们必须从以服务器为中心的视角来看待。以服务器为视角将只看到客户端访问的频率和处理每个请求所花费的时间。让我们考虑一个典型例子，即银行的出纳员。出纳员通常不知道您是什么时候到的，也不知道您是从哪里来的。他们所知道的只是您在这里，而且您要让他们为您做一些事情。现在，队列中有多少人将取决于人们到达的速度，以及满足他们的要求所花的时间。
        　　比队列中有多少人更重要的是，随着后来的人不断补进队列，房间中的人数是在减少、保持不变还是在增加？与之相随的另一个问题是，人们进入队列的速度与离开的速度相比，是快一些、相同还是慢一些？如果离开的速度要比到达的速度快，那么处理请求的速度要比递交请求的速度快。第二种情况说明刚刚处理完一个客户，下一个就到达了。最后一种情况则说明人们到达的速度要比处理的速度快。用数学术语来说，第一种系统是收敛的，第二种处于稳定状态，第三种则是发散的。这三种情况中房间中的人数都是由利托氏定理(Little's Law)决定的。
        只做力所能及的
        　　对于外行来说，利托氏定理说明了您只能做这么多工作。其数学版本是这么说的：系统中的请求数等于请求到达的速度乘以它们在系统中的时间所产生的积。如果它们在系统中的时间取决于流出系统的速度（通常称为服务时间），那么就可以通过观察请求到达的频率（请求到达间隔时间）并与服务时间比较，而确定系统处于哪种状态。
        　　对于每种情况，利托氏定理都描述了系统是如何处理工作负载的。虽然状态可能会发生瞬时的迸发和间歇，总体的趋势还将由平均的状况决定。例如，在收敛系统中，可能会由于许多人同时进入队列而产生瞬时的暴涨，但是队列仍将会腾空，因为收敛系统的倾向就是趋向空闲。但是，第三种场景是发散的，其中的请求数将会无限增长。它会吗？这个问题的答案与如何定义发出请求的全域有关。
        　　在某个随机的时间点，全域中的用户将发出一个请求。这肯定是从以服务器为中心的视角来看全域了。大多数系统都基于一个假设，即在任一个给定的时间点，全域中只有一部分会发出请求。经验告诉我们，在许多因特网应用程序中，全域中有10％在任意时间点都是活动的。我们需要知道这种信息，如果我们要定义实际的压力测试的话。例如，如果全域中有1000个用户，我们会预料有100个每时每刻都在使用系统。由于我们估计会有10％的并发使用，用户库又有 1000个用户，所有我们的测试应该模拟100个用户重复执行一些请求系列。用这种方法定义测试的危害是它反映的是客户端的视角。
        　　当我们从以服务器为中心的视角转向以客户端为中心的视角后，就看不到向服务器发送请求的速度了。如果我们限制或固定为执行用户请求所分配的用户（线程）数目，那么就看得更模糊了。在这种情况下进行测试，我们将看到服务器正在处理稳定的请求流，而处理请求的时间似乎越来越长。
        每个人都可以参与
        　　如果我们让模拟线程尽可能快地发出请求，就是在模拟整个全域（甚至更多）的用户都在同一时间发出请求。我们假定服务器模型为单一的，因为这样便于理解；多服务器模型的工作方式是相同的，只是更快一些。系统将把请求排队，并且每次只处理一个。一旦有一个请求清除，线程会立即返回队列头部发出下一个请求。虽然这种事件顺序似乎说明我们处理的是一个稳定状态的系统，但我们实际上是在处理发散系统。它之所以看起来像稳定状态系统的惟一原因是，我们限制了发出请求的线程数目。正如前面所提到的，在发散系统中，每个后继用户的响应时间都要比前一个所经历的时间长。这意味着平均响应时间将不断地增长而没有限制。尽管如此，但是我们人为地限制了客户端的数目，因此平均响应时间将稳定在一个点上，该点取决于客户端数目与处理单个请求所花费时间的乘积。这里所说的这种系统中的响应时间包括花在队列中的时间，而且因为花在队列中的时间比预料的要少，所以我们又人为扩大了测量值。最终结果是您的测试限制了您确定系统的可伸缩性的能力。
        如何修复
        　　要修复压力测试，需要知道用户/线程发出请求的速度。所有用户的速度之和就转化为服务器接受请求的速度。一旦确定了这个值，就可以对工具发出请求的速度进行调整。下面的表列出了几个可以用来维持50个请求每秒(RPS)的值。从服务器的视角来看，工具需要每20ms提供一个请求。这种观点反映的是单个线程的情况。如果工具配置了两个线程，那么对于每个线程，都应该维持40ms的请求间时间间隔。表中还列出了使用5个线程和10个线程的情况下的时间间隔。
线程数目         线程频率         请求间时间间隔(inter-request interval)        
        1         50/sec        20ms       
2        25/sec        40ms       
5        10/sec        100ms       
10        5/sec        200ms       
        抉择
        　　从理论上来说，这个表展示了如何使用1个、2个、5个、10个线程来实现所要求的维持50个RPS的目标。但是如果服务时间比请求间时间间隔长的话会怎么样呢？这种情况下驻留在服务器中的线程不能使下一个请求排入队列，工具也不能交付50RPS的预期负载。为了避免这种情况发生，需要在系统中构建一些空余时间(slack)。使用大量线程的方案对我们来说通常是不可行的，因为我们很有可能要受到可用的硬件数目和/或许可证数目（对于商业的负载测试工具来说）的限制。解决方法其实很常见，就是我们需要达到一种维持合适的请求间时间间隔与使用过多的（计算/许可）资源之间的平衡。我们要始终记住，如果测试工具使用的资源（不管是硬件、软件或是线程）很少，就会影响我们测试的有效性。
        三思而后行
        　　我们使用Apache JMeter来对随机的Web应用程序进行负载测试，以说明压力测试工具是如何影响测试结果的。除了要知道应用程序的入口点是Servlet，应用程序的功能以及如何实现的详细信息对于我们的讨论来说并不重要。
        　　图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秒。
        结束语
　　在开始性能调优实践（或者为性能确定基准）之前，需要确认工具不会影响测试。配置良好的工具不会让我们测量不该测量的数据。不能交付适当的负载或会使我们测量偶然的响应时间的测试工具将会影响对应用程序进行性能调优的工作。要想知道是否发生了这种情况，关键是要度量工具以正常速度运行的效果。这种效果可以由工具满足或支持所要求的每秒的事务或请求数目的能力来确定。工具不应该立刻轮换线程（来发出下一个请求）。如果发生了这种情况，就需要降低工具的速度，以免人为地使服务器的容量溢出。通常需要试验几次以达到测试工具的适当的平衡配置。在测试的早期阶段，不要把重点放在响应时间（它会随着对应用程序调优的过程而改善）上，而是要放在配置好工具上。最后，不要害怕放慢速度，因为这样做可能有助于弄清楚到底是什么影响了应用程序的性能。