详解JMeter远程测试（1）
如果运行JMeter客户端的机器性能不能满足测试需要，那么测试人员可以通过单个JMeter GUI客户端来控制多个远程JMeter服务器，以便对服务器进行压力测试，模拟足够多的并发用户。通过远程运行JMeter，测试人员可以跨越多台低端计算机复制测试，这样就可以模拟一个比较大的服务器压力。一个JMeter GUI客户端实例，理论上可以控制任意多的远程JMeter实例，并通过它们收集测试数据，如图11-3所示。这样一来，就有了如下特性：
保存测试采样数据到本地机器。
通过单台机器管理多个JMeter执行引擎。
没有必要将测试计划复制到每一台机器，JMeter GUI客户端会将它发往每一台JMeter服务器。
每一台JMeter远程服务器都执行相同的测试计划。JMeter不会在执行机间做负载均衡，每一台服务器都会完整地运行测试计划。
在1.4GHz～3GHz的CPU、1GB内存的JMeter客户端上，可以处理线程100～300。但是Web Service例外。XML处理是CPU运算密集的，会迅速消耗掉所有的CPU。一般来说，以XML技术为核心的应用系统，其性能将是普通Web应用的10%～25%。另外，如果所有负载由一台机器产生，网卡和交换机端口都可能产生瓶颈，所以一个JMeter客户端线程数不应超过100。
采用JMeter远程模式并不会比独立运行相同数目的非GUI测试更耗费资源。但是，如果使用大量的JMeter远程服务器，可能会导致客户端过载，或者网络连接发生拥塞。
请注意，假如测试人员将JMeter执行引擎安装在应用服务器（测试目标）上，那么这显然会加重应用服务器的负担，测试结果也将变得不可信。作者推荐的方式是将JMeter远程服务器放在应用服务器（测试目标）所在的同一个网段内。这样做既可以减少JMeter收集测试结果对网络产生的冲击，又可以避免对应用服务器（测试目标）性能产生影响。
图11-3 JMeter远程测试原理图
下面是启动JMeter远程测试的基本步骤：
步骤1：配置节点
确保所有节点（JMeter客户端和JMeter远程服务器）运行相同版本的JMeter。尽可能在所有操作系统上使用相同的Java版本。
如果测试用到了外部数据文件，那么请注意这些文件不会被JMeter客户端分发，因此测试人员需要确保每台执行机上都保存了这些数据文件（其所在目录也必须正确）。如果有必要，用户可以为每台执行机设置不同的属性变量，即在JMeter远程服务器上编辑user.properties或者system.properties文件。这些属性将会在JMeter远程服务器启动时被识别，并有可能被应用到测试计划之中，从而影响测试执行（例如，与其他远程服务器发生交互）。另外，不同的JMeter远程服务器可能会使用不同内容的数据文件（例如，每台服务器必须使用不同的ID，就以此来划分数据文件）。
步骤2：启动远程服务器
要启动JMeter远程节点，请在执行机上运行JMETER_HOME/bin/jmeter-server （UNIX）或者JMETER_HOME/bin/jmeter-server.bat（Windows）脚本。
请注意，每个远程节点上只能运行一个JMeter远程服务器脚本，除非采用不同的RMI端口。从JMeter 2.3.1开始，JMeter远程服务器会自己启动RMI注册；用户没有必要单独启动RMI注册。假设测试人员一定要单独启动RMI注册，可以在远程节点上定义JMeter属性server.rmi.create=false。
默认情况下，JMeter远程服务器的RMI使用动态端口号。这样就会为防火墙配置带来麻烦，因此JMeter 2.3.2及其以后的版本，会检查JMeter属性server.rmi.localport。如果该值非零，JMeter远程服务器就会用它来作为本地端口号。
步骤3：将JMeter远程服务器的IP地址添加到客户端属性文件中
编辑JMeter控制机的属性文件。在/bin/jmeter.properties文件中找到属性"remote_hosts"，使用JMeter远程服务器的IP地址作为其属性值。可以添加多个服务器的IP地址，以逗号作为分隔。
请注意测试人员还可以使用-R命令行选项来指明将会使用的远程服务器。这与使用-r 和-Jremote_hosts={服务器列表}的效果相同。例如jmeter -Rhost1,127.0.0.1,host2。
如果测试人员定义JMeter属性server.exitaftertest=true，那么远程服务器在运行完单个测试后就会退出。-Z标志也有同样的效果，参见后面的内容。
最新内容请见作者的GitHub页：http://qaseven.github.io/