如何调整压力测试工具

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

如何进行测试?

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

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

测试方式将影响测试

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

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

只做力所能及的

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

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

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

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

原文转自：http://www.uml.org.cn/Test/200808077.asp