进行简单的JMeter并发测试

设置 JMeter

JMeter 是一个功能强大的开源 Java 应用程序，具有多种功能，这使得在其中设置测试计划令人望而生畏。在浏览有关该主题的文档时，我在Drupal 性能测试套件页面上找到了一个特定于 Drupal 的示例 JMeter 计划。该计划附带设置了 HTTP 请求、标头和侦听器元素。下图显示了计划文档的外观。

以下是使用它之前需要做的一些自定义：

激活与您的 Drupal 版本对应的用户定义变量元素;停用另一个。

将主机变量设置为您要测试的服务器的主机名。

在两个线程组中，设置线程数。这是您希望模拟的并发用户数。

在两个线程组中，设置Loop Count。这个数字将决定每个线程运行多少次，从而控制测试的长度。如果您想了解服务器在恒定负载下的性能，请针对一分钟的测试。第二长的测试可能不会产生相关的结果，因为服务器可能需要一些时间在负载变化的情况下稳定下来——例如，需要创建新的服务器线程。如果您有目标时间和吞吐量的近似值(服务器在一秒钟内可以处理的请求数)，则可以使用以下公式计算循环计数：

循环计数 = 吞吐量 * 时间 / 线程数。

修改、添加或删除 HTTP 请求元素，以便它们反映您希望随请求获取的页面。

可以在HTTP 标头管理器元素中调整Keep-alive和Accept-Encoding标头，尽管在大多数浏览器中通常会发现 keep-alive 和压缩启用，因此保持它们不变应该没问题。

在windows上试用后发现JMeter占用了很多内存，最终会抛出java.lang.OutOfMemoryError: GC overhead limit exceeded错误。可以通过在 jmeter.bat 中设置内存限制来缓解该问题。将限制设置为 512MB，它能够运行大约 3100 个请求。虽然我没有超过这个数字，但我仍然增加了内存限制，以便它在接近这个数字并填满内存时不会影响速度。

准备数据

为了了解我应该模拟多少并发用户，我检查了站点统计信息。网站的所有者组织活动，这往往会比平时吸引更多的访问者访问网站。因此，服务器负载偶尔会出现峰值，如下图所示。

2010 年 5 月 1 日至 2011 年 5 月 1 日之间的访客。访客总数：3,835,880

为了了解服务器如何处理不断增加的流量，我想在并发用户数量逐渐增加的情况下运行多个测试。我选择了最小的数字来开始测试，即基于一个月的数据的平均并发访问者数。当然，这并不能告诉我们太多关于任何给定时刻的实际负载，但它给出了服务器不断受到的压力基线。下图显示了用于计算平均并发访问者数的数据。

2011 年 4 月 1 日至 2011 年 4 月 30 日期间的

访问者总访问者：366,975

总浏览量：937,643

平均。现场时间：87秒

我们在 Google Analytics 中随时可用的数据是访问者数量和平均访问时长。根据这些数字，可以使用以下公式计算并发用户数：

并发用户数 = 访问者率 * 访问时间

因为我们有以秒为单位的访问时长，所以我们还需要将每月访问者的数量投影到秒。

访客率 = 366,975 访客/(30 天 * 24 小时 * 60 分钟 * 60 秒)= 0.1415 访客/秒

这使

并发用户数 = (0.1415 访问者/秒) * 87 秒 = 13 访问者

第二个测试周期基于对应于最近峰值的数据。这显示了服务器将来肯定会遇到的流量。我选择了 3/11 的峰值，这是今年数据中最大的峰值。下图显示了 3 月 11 日访客的每小时图表。

2011 年 3 月 11 日峰值的小时图。

上午 9 点高峰期的访客：上午 9 点高峰期的 1,570 次

浏览量：

平均5,328 次。现场时间：108秒

上午 9 点高峰的访客人数为 1570。应用之前使用的公式，我们得到

访客率 = 1,570 访客 / 60 分钟 / 60 秒 = 0.4361 访客 / 秒

并发用户数 = (0. 4361 访问者/秒) * 108 秒 = 48 访问者

最后，在第三轮测试中，我想保持安全，并提出一个超过任何预期激增的数字。有理由认为，目前最大峰值两倍的负载将是一个极端事件，并且在正常运行期间不太可能发生(或者至少会有一些警告信号)。因此，我在最后一轮测试中将访问者参数设置为 100。

这给了我 13、48 和 100 个并发访问者来测试。接下来，我必须决定应该针对哪些页面运行测试。无论我选择什么都是不现实的，因为数百名访问者不太可能点击相同的几个页面。我认为我能做的最好的事情就是针对最常访问的页面运行测试。这样，测试请求与现实生活中的大部分请求重叠。

我正在测试的站点上访问量最大的页面是主页，其中包含多个 Drupal 视图。还有一个页面有很多入站链接，并且比所有其他页面更频繁地被请求;我也包括在内。我测试的第三个页面是 Drupal 节点页面。节点页面在结构上非常相似，并且构成了绝大多数页面。我将这些页面分别称为 Homepage、Landing Page 和 Node。

运行测试

负载是在与服务器分开的网络中的单独计算机上生成的。这样，测试结果包括当有人请求页面时发挥作用的所有因素，包括网络延迟和页面呈现时间。此外，如果负载是在为页面提供服务的同一台机器上生成的，负载生成器会占用服务器的一些资源，从而影响结果。

在测试期间，我使用top命令监控服务器负载。我注意到在测试结束时读取的 1 分钟平均值。因为所有测试的运行时间都超过 1 分钟，所以平均值中的所有数据都被测试负载覆盖。测试结果是从测试计划的摘要报告元素中获取的。我多次运行测试并获得了我能够重现的结果。

站点上启用了 Drupal 页面缓存。没有可用的公开注册;只有组织的员工才有用户帐户;大部分流量来自匿名用户。

测试结果如下：

13个并发访问者，100个循环

负载：0.56

48个并发访问者，60个循环

负载：0.79

100个并发访问者，30个循环

负载：0.9

最后，我对经过身份验证的用户进行了一项测试，以便将服务匿名用户的性能与服务经过身份验证的用户的性能进行比较。

13 个并发访问者，30 个循环，经过身份验证的用户

加载 14.51

(登录页面的行没有显示)

结论和见解

引人注目的第一件事是，经过身份验证的用户的吞吐量是匿名用户的 1/7。这源于站点上启用了 Drupal 页面缓存，并且匿名用户从缓存中提供服务，而页面为经过身份验证的用户的每个页面加载重新生成。该测试还将服务器负载增加到 14.51，这表明有点过载。考虑到该服务器采用 4 核 Intel Xeon L5420 处理器，服务器负载不应长时间保持在 4 以上，因为这意味着 4 核的充分利用。对于匿名用户，对于多达 100 个并发访问者来说，它并没有接近过载。

接下来我注意到的是首页的加载速度比其他页面慢得多。这是一个意料之外的结果，因为如果启用了页面缓存，那么所有页面都应该从缓存中提供，在这种情况下，我看不出首页可能会慢得多的任何原因。这可能需要我进一步调查。

可以与 Analytics 中可用数据进行比较的一项测试结果是吞吐量。根据页面浏览量，可以计算出为给定数量的请求提供服务所需的吞吐量。我使用了上图中峰值的数据作为比较的基础。应用公式Number of Pageviews / Length of Time Interval = Throughput，我们得到

5,328 个请求/(60 分钟 * 60 秒)= 1.45 个请求/秒

这远低于为多达 100 个并发匿名访问者测量的容量。对于经过身份验证的用户，这将非常接近服务器实际可以服务的速率。如果网站决定开放注册并鼓励用户登录，则应考虑到这一点。

重要的是要注意并发用户和浏览量之间的因素 - 或平均浏览量，正如 Analytics 所说的 - 会有所不同。与另一站点上的大量访问者相比，少数并发访问者可以在一个站点上发起更多请求。出于这个原因，知道服务器可以处理给定数量的并发访问者可能不够，也可能不够，具体取决于这些访问者产生的网页浏览量。如果您想了解更多相关知识，可以关注一下赢咖4的Java赢咖4在线学习，里面的课程由浅到深，适合没有基础的小伙伴学习，希望对大家能够有所帮助。