JMeter的分布式测试_jmeter集群部署 百万级并发数

作为一个纯 JAVA 的GUI应用，JMeter 对于CPU和内存的消耗还是很惊人的，所以当需要模拟数以千计的并发用户时，使用单台机器模拟所有的并发用户就有些力不从心，甚至还会引起JAVA内存溢出的错误。不过，JMeter 也可以像 LoadRunner 一样通过使用多台机器运行所谓的 Agent来分担 Load Generator 自身的压力，并借此来获取更大的并发用户数。根据 JMeter官方文档的署名，你需要自己完成这个配置，不过不用担心，这将非常简单 ^_^

1.              在所有期望运行 JMeter 作为 Load Generator 的机器上安装 JMeter，并确定其中一台机器作为 Controller，其他的机器作为 Agent。然后运行所有 Agent 机器上的JMeter-server.bat文件——假定我们使用两台机器 192.168.0.1 和 192.168.0.2 作为 Agent；

2.              在Controller 机器的 JMeter 安装目录下找到 bin 目录，再找到 JMeter.properties 这个文件，使用记事本或者其他文字编辑工具打开它；

3.              在打开的文件中查找“remote_hosts=”这个字符串，你可以找到这样一行“remote_hosts=127.0.0.1”。其中的 127.0..0.1 表示运行JMeter Agent 的机器，这里需要修改为“remote_hosts=192.168.0.1:1664,192.168.0.2:1664”——其中的 1664 为 JMeter 的 Controller和 Agent 之间进行通讯的默认 RMI 端口号；

4.              保存文件，并重新启动 Controller 机器上的 JMeter.bat，并进入 Run -> Remote Start 菜单项。

1.所谓的 Agent，是指运行了 jmeter-server.bat 的那台机器；
2.所谓的 Controller，是指运行了 JMeter（UI 客户端或者命令行方式）的那台机器；
3.Agent 可以和 Controller 运行在同一台机器上，也可以运行多个 Agent 在同一台机器上；
4.JMeter 中不能对单个 Agent 设置并发用户数量，例如：有三个 Agent，你在 JMeter 中定义了 100 个并发用户，那么就是 3 个 Agent 每个都模拟 100 个用户，一共是 300 个。

1 　引言
   互联网应用日趋广泛,其中Web 访问占据了最大比例,而且许多应用系统也逐渐从C/ S 结构转为更加灵活的B/ S 结构。随着流量的激增,许多应用系统的同时在线人数超过百万,一些热门Web 应用系统变得反应迟缓甚至有可能瘫痪,
既给用户造成不便也给运营商带来损失,甚至给国家形象造成损失。前段时间,2008 奥运门票在线销售系统就因访问量太大而崩溃,导致国家形象、政府声誉受损。出现这些情况的原因可能是多方面的,
其中常见的一类可归结为系统运行环境(服务器硬件、网络带宽等) 配置得不合理或者Web 应用本身在长时间高负荷下稳定性的欠缺。这些问题能否在Web 应用的开发阶段被发现和解决?Web应用属于软件的一种,严格的测试必须贯穿其开发的全过程中。
为了保证Web 系统的良好性能,应该对Web 系统进行性能测试,以找出性能瓶颈并对其进行优化。因此,在Web 应用的各种软件测试工作中,负载测试被特别地提出来加以重视。
2 　Web 应用系统特点及负载测试概念
   现在的Web 应用系统基本上都为三层结构并采用动态技术,例如J SP、ASP 等,业务逻辑都需要与数据库连接。Web 应用系统基本都采用结构模型。其特点分析如下:
(1) 采用瘦客户端,业务逻辑的处理集中于服务器一侧,客户端所需资源少。这在系统资源层面上决定了用客户端模拟百万级负载的可能性。
(2) 采用标准的用户界面———浏览器,在客户端提供给用户的是一个有限的、标准化的操作集。这有助于简化负载测试中对用户操作行为的模拟。
(3) 客户端与服务器间采用统一的交互方法和通信模式,有利于跨平台负载测试的实现。负载测试是在输入端设置请求Web 服务的客户端数目,逐步增加请求Web 服务的客户端数目,每次得到多个客户端的平均响应时间,对比分析每次客户端数增大以后Web 服务的平均响应时间。
该测试能够评价当负载达到一定程度时,Web 服务的时间变化情况及服务器的运行状况(包括CPU 、内存、网络等的使用率) ,有助于评价站点服务质量的稳定性。

3 　利用自动化测试工具JMeter 进行负载测试
3. 1 　JMeter 介绍
   人工进行大规模的请求模拟和响应确认无疑是困难的,需要借助自动化的工具来实现。现有一些商业测试工具软件可在不同程度上实现自动化Web 负载测试工作,如QALoad、LoadRunner 等。它们功能强大,花费也相对昂贵,这在一定程度上限制了Web 负载测试的普遍应用。
准确地说,开源的JMeter 代表一种分布式软件测试架构,其设计目标是建成一个平台无关、多用途的开放测试平台。JMeter 可以通过原有的分布式测试框架,实现十万级虚拟用户(十万用户同时在线) 的负载测试功能。
3. 2 　JMeter 分布式测试框架
   这里“分布式”指的不仅仅是测试在几个机器上同时进行,分布测试还指在测试过程中不同的测试部分互相之间有交互,以某种合适的方式协调和同步。实际上,同步是分布式测试的关键环节。
另外,管理和配置分布式测试也是很关键的内容。为了方便分析测试结果,所有机器的测试结果应该自动收集在一起。JMeter 是通过RMI 协议来实现分布式测试的框架。RMI 的本质就是实现在不同JVM 之间的调用,它的实现方法就是在两个JVM 中各开一个Stub 和Skeleton ,
二者通过Socket 通信来实现参数和返回值的传递。作为一个纯J ava 的GUI 应用,JMeter 对于CPU 和内存的消耗还是很惊人的。所以,当需要模拟数以万计的并发用户时,使用单台机器模拟所有的并发用户就有些力不从心,甚至还会引起J ava 内存溢出的错误。
不过,JMeter 也可以通过分布式测试框架,通过使用多台机器运行所谓的Agent 来分担Load Generator 自身的压力,并借此来获取更大的并发用户数。实验结果表明,在一般的台式机上( P4 2. 0 ,512M 内存) 使用JMeter 只能模拟约五万个虚拟用户,如果要实现百万级的负载测试,则需要利用分布式的测试方法。
JMe2ter 是一个分布式Web 负载测试工具,这意味着测试可以被部署在多台远程主机运行,用户甚至可以在不同测试主机上指定不同的场景。部署分布式测试时需运行JMeterServer ,用其注册位于不同主机的测试组件,以协调彼此间的通讯。
分布式测试是利用几台或者几十台主机协作共同完成测试任务。

3. 3 　JMeter 分布式测试框架改造
   JMeter 现有的分布式测试框架只是一个想法。JMe2ter 现有框架中所有的测试脚本都要从测试主机传送到测试从机,而测试结果又要从测试从机传送到测试主机,测试主机收集所有从机的测试结果并显示出来。如果虚拟用户的数量大的话,这个过程需要传输的数据很多,对测试主机有很高的要求。
根据JMeter 的官方文档,该测试框架下一个测试主机最多只能带3～5 个从机[2 ] ,实验结果也证明确实如此。我们用实验室服务器( P4 2. 4 3 2 ,1G3 2 内存) 附带三台测试从机( P4 2. 0 ,512M 内存,各并发五万个虚拟用户) ,测试主机在运行5 分钟后J ava 应用程序内存溢出,JMeter 测试主程序崩溃。
在实际的负载测试中需要并发更多的负载,而JMeter 现有的框架最多只能做到十万级的负载,与实际应用还有一定差距,所以需要对其分布式测试框架进行改造。
我们应用数据库技术,结合原有JMeter 的分布式测试框架组成的分布式测试单元(可并发十万负载) ,然后用一台测试主机对各个测试单元进行管理,并使各个测试单元的测试结果输入到数据库中构成新的分布式结构模型。
分布式测试可以让许多台主机共同承担测试任务,一台主机由于硬件的原因不可能完成五万个以上虚拟用户请求测试。要模拟百万级的测试,只有让20 个以上的主机共同分担任务。每台主机模拟五万个虚拟用户请求,则总共就能完成20 3 50 000 的负荷测试,
从而达到百万计的负载技术指标。由于大量的数据传输使得测试主机很大部分任务是在传输数据,直接导致测试主机程序的内存溢出。我们应用数据库技术对上述分布式测试模型进行了改造,使各个测试分机的测试结果直接存入数据库中,而不转发给测试主机,测试主机在显示测试结果时再从数据库中读取并进行分析和综合。
这个测试框架可以实现基于JMeter 的百万级的Web系统负载测试,
(1) 测试代理主机运行JMeter 的图形界面,测试代理主机本身也是一个测试从机,和它下面的一个测试从机共同构成一个两台计算机的小型分布式测试单元。
(2) 测试主机通过管理界面(自己扩展JMeter 编写的程序) 来管理和运行下面的JMeter 测试代理主机。
(3) 所有的测试代理主机从数据库中读取测试计划脚本,并运行测试任务。一个测试代理单元创建2 ×50 000个虚拟用户,测试主机把获得的测试结果直接存入数据库中。
(4) 测试主机的管理界面再从数据库中实时读出各个测试代理主机写入的测试结果,并以图表形式显示出来。

  由于JMeter 是开源产品,对其源代码进行修改和扩展功能都很方便。我们对JMeter 进行了修改,使其测试的结果和测试的脚本都存入数据库服务器中。图形化的测试结果都在测试运行的过程中从数据库实时读出。各个测试的客户端只需要负责虚拟并发用户,
发送HTTP 请求,并把请求的结果写入数据库的表格中,从而减少测试主机的负担。测试主机只负责显示最后的结果和管理各个测试单元。
4 　结束语
   基于Web 系统的测试、确认和验收是一项重要而富有挑战性的工作。由于Web 页数目多且变动频繁,对其测试如果单靠手工是无法进行的, 必须有测试工具的参与。JMeter 可以说是一个很好的自动化测试工具。
在实际的测试环境中,可以通过JMeter 测试的结果分析出系统的性能瓶颈,从而提高系统的性能。但是,如何分析测试得到的数据并找出系统中的瓶颈,还需要一定的经验积累。我们通过对JMeter 的分布式测试框架的改造,
在JMeter 的源代码中扩展了对数据库中的测试结果和测试脚本的读写功能,并且做了一个简单的管理程序来管理局域网中运行了JMeter 的分布式测试单元和显示测试结果。
使用新的架构,在实验室的条件下使用25 台计算机实现了对实验室的BBS 服务器的百万级负载测试,从而解决了JMeter 不能并发百万级负载的问题,使Web 应用系统能够接受百万级的负载测试。