如何调整压力测试工具

您是否曾经不得不对应用程序进行压力测试，而最后却发现不明白结果表明什么意义？也许问题不是出在应用程序上。也许问题出在配置压力测试工具的方式上。如果您曾经经历过这种情况，或者正要进行压力测试，您就需要考虑以下几个方面。

如何进行测试？

　　我经常遇到一些开发团队，他们收到诸如“客户端将每小时处理20个客户”此类的性能需求。团队就试图把该需求转化为某种测试。执行这种测试的常见方法就是以死循环的形式对服务器进行反复请求，然后静观其效。通常事情进行得不是很顺利，这就是为什么随后我会作为一个性能专业化方面的顾问“遇见他们”的原因。通常我问的第一个问题是：“您是如何进行测试的？”一般来说，答案会是：“我们将请求置于循环中，然后计算服务器可以处理的请求的数目。”正是这种回答使我明白首先要做的就是调整测试工具本身。

　　如果您不明白上述测试有什么问题，不要担心——有很多人和您一样。进行一次切实可行的压力测试并不像乍看之下那么简单。遇到的问题可能非常微妙，而且通常只有采用不那么简单的方法来理清情况才能看清问题。但是这并不是让您目光呆滞地深入研究马尔可夫链(Markov chains)、状态改变模型、排队理论、概率分布等等，让我们以一种不那么乏味的、更通俗易懂的方式来说明如何解决这个在许多压力测试中出现的常见问题。

测试方式将影响测试

　　我们首先要明白的是，虽然测试通常都是从客户端活动的角度定义的，但是它们必须从以服务器为中心的视角来看待。以服务器为视角将只看到客户端访问的频率和处理每个请求所花费的时间。让我们考虑一个典型例子，即银行的出纳员。出纳员通常不知道您是什么时候到的，也不知道您是从哪里来的。他们所知道的只是您在这里，而且您要让他们为您做一些事情。现在，队列中有多少人将取决于人们到达的速度，以及满足他们的要求所花的时间。

　　比队列中有多少人更重要的是，随着后来的人不断补进队列，房间中的人数是在减少、保持不变还是在增加？与之相随的另一个问题是，人们进入队列的速度与离开的速度相比，是快一些、相同还是慢一些？如果离开的速度要比到达的速度快，那么处理请求的速度要比递交请求的速度快。第二种情况说明刚刚处理完一个客户，下一个就到达了。最后一种情况则说明人们到达的速度要比处理的速度快。用数学术语来说，第一种系统是收敛的，第二种处于稳定状态，第三种则是发散的。这三种情况中房间中的人数都是由利托氏定理(Little's Law)决定的。

只做力所能及的

　　对于外行来说，利托氏定理说明了您只能做这么多工作。其数学版本是这么说的：系统中的请求数等于请求到达的速度乘以它们在系统中的时间所产生的积。如果它们在系统中的时间取决于流出系统的速度（通常称为服务时间），那么就可以通过观察请求到达的频率（请求到达间隔时间）并与服务时间比较，而确定系统处于哪种状态。

　　对于每种情况，利托氏定理都描述了系统是如何处理工作负载的。虽然状态可能会发生瞬时的迸发和间歇，总体的趋势还将由平均的状况决定。例如，在收敛系统中，可能会由于许多人同时进入队列而产生瞬时的暴涨，但是队列仍将会腾空，因为收敛系统的倾向就是趋向空闲。但是，第三种场景是发散的，其中的请求数将会无限增长。它会吗？这个问题的答案与如何定义发出请求的全域有关。

　　在某个随机的时间点，全域中的用户将发出一个请求。这肯定是从以服务器为中心的视角来看全域了。大多数系统都基于一个假设，即在任一个给定的时间点，全域中只有一部分会发出请求。经验告诉我们，在许多因特网应用程序中，全域中有10％在任意时间点都是活动的。我们需要知道这种信息，如果我们要定义实际的压力测试的话。例如，如果全域中有1000个用户，我们会预料有100个每时每刻都在使用系统。由于我们估计会有10％的并发使用，用户库又有 1000个用户，所有我们的测试应该模拟100个用户重复执行一些请求系列。用这种方法定义测试的危害是它反映的是客户端的视角。

　　当我们从以服务器为中心的视角转向以客户端为中心的视角后，就看不到向服务器发送请求的速度了。如果我们限制或固定为执行用户请求所分配的用户（线程）数目，那么就看得更模糊了。在这种情况下进行测试，我们将看到服务器正在处理稳定的请求流，而处理请求的时间似乎越来越长。

每个人都可以参与

　　如果我们让模拟线程尽可能快地发出请求，就是在模拟整个全域（甚至更多）的用户都在同一时间发出请求。我们假定服务器模型为单一的，因为这样便于理解；多服务器模型的工作方式是相同的，只是更快一些。系统将把请求排队，并且每次只处理一个。一旦有一个请求清除，线程会立即返回队列头部发出下一个请求。虽然这种事件顺序似乎说明我们处理的是一个稳定状态的系统，但我们实际上是在处理发散系统。它之所以看起来像稳定状态系统的惟一原因是，我们限制了发出请求的线程数目。正如前面所提到的，在发散系统中，每个后继用户的响应时间都要比前一个所经历的时间长。这意味着平均响应时间将不断地增长而没有限制。尽管如此，但是我们人为地限制了客户端的数目，因此平均响应时间将稳定在一个点上，该点取决于客户端数目与处理单个请求所花费时间的乘积。这里所说的这种系统中的响应时间包括花在队列中的时间，而且因为花在队列中的时间比预料的要少，所以我们又人为扩大了测量值。最终结果是您的测试限制了您确定系统的可伸缩性的能力。

如何修复

　　要修复压力测试，需要知道用户/线程发出请求的速度。所有用户的速度之和就转化为服务器接受请求的速度。一旦确定了这个值，就可以对工具发出请求的速度进行调整。下面的表列出了几个可以用来维持50个请求每秒(RPS)的值。从服务器的视角来看，工具需要每20ms提供一个请求。这种观点反映的是单个线程的情况。如果工具配置了两个线程，那么对于每个线程，都应该维持40ms的请求间时间间隔。表中还列出了使用5个线程和10个线程的情况下的时间间隔。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有