如果您的JMeter客户端计算机无法使用性能方面,要模拟足够的用户来增强压力或受限于网络级别,则可以选择从单个JMeter客户端控制多个远程JMeter引擎。通过远程运行JMeter,您可以跨许多低端计算机复制测试,从而模拟服务器上的较大负载。JMeter客户端的一个实例可以控制任意数量的远程JMeter实例,并从中收集所有数据。这提供以下功能:
- 将测试samples保存到本地机器
- 从单个机器管理多个JMeter Engines
- 无需将测试计划复制到每个服务器 - 客户端将其发送到所有服务器
注意:所有服务器都运行相同的测试计划。JMeter不会在服务器之间分配负载,每个都运行完整的测试计划。所以如果你设置1000个线程并且有6个JMeter服务器,你最终会注入6000个线程。
然而,远程模式确实使用更多的资源,而不是独立运行相同数量的非GUI测试。如果使用许多服务器实例,客户端JMeter可能会变得过载,客户端网络连接也会如此。这通过切换到“Stripped modes ”模式(见下文)得到了改进,但是您应该始终检查您的客户端是否没有超载。
请注意,虽然您可以在应用程序服务器上执行JMeterEngine,但您需要注意的是,这将在应用程序服务器上添加处理开销,因此您的测试结果将会受到某种程度的污染。建议的方法是将一台或多台计算机与您配置为运行JMeter Engine的应用程序服务器位于同一个以太网段上。这将最大限度地减少网络对测试结果的影响,而不会影响应用服务器本身的性能。
步骤0:配置节点
确保所有节点(客户端和服务器):
- 正在运行完全相同版本的JMeter。
- 在所有系统上都使用相同版本的Java。使用不同版本的Java可能会工作,但不鼓励。
如果测试使用任何数据文件,请注意,这些文件不会由客户端发送,因此请确保这些文件在每个服务器上的相应目录中可用。如果需要,您可以通过编辑每个服务器上的user.properties或system.properties文件来为属性定义不同的值。这些属性将在服务器启动时被提取,并且可能在测试计划中用于影响其行为(例如连接到其他远程服务器)。或者在测试使用的任何数据文件中使用不同的内容(例如,如果每个服务器必须使用唯一的ids,在数据文件之间划分这些内容)
步骤1:启动服务器
要在远程节点中运行JMeter,请通过运行JMETER_HOME / bin / jmeter-server(unix)或JMETER_HOME / bin / jmeter-server.bat(windows)脚本在要运行的所有计算机上启动JMeter服务器组件。
请注意,除非使用不同的RMI端口,否则每个节点上只能有一个JMeter服务器。
自JMeter 2.3.1起,JMeter服务器应用程序启动RMI注册本身;没有必要单独启动RMI注册。要还原到以前的行为,请定义JMeter属性
server.rmi.create = FALSE
在服务器主机系统上。
默认情况下,RMI为JMeter服务器引擎使用动态端口。这可能会导致防火墙出现问题,因此您可以定义JMeter属性server.rmi.localport来控制此端口号。如果这不是零,它将被用作服务器引擎的本地端口号。
步骤2:将服务器IP添加到客户端的属性文件
编辑控制JMeter机器上的属性文件。在JMETER_HOME / bin / jmeter.properties中,找到名为“remote_hosts”的属性,并添加运行JMeter服务器IP地址的值。可以添加多个这样的服务器,以逗号分隔。
请注意,您可以使用-R命令行选项来指定要使用的远程主机。这与使用-r和-Jremote_hosts = {serverlist}的效果相同。例如
jmeter -Rhost1,127.0.0.1,host2
如果定义JMeter属性server.exitaftertest = true,那么在运行单个测试后,服务器将退出。另见-X标志(如下所述)
步骤3a:从GUI客户端启动JMeter客户端以检查配置
现在您可以开始控制JMeter客户端了。对于MS-Windows,使用脚本“bin / jmeter.bat”启动客户端。对于UNIX,请使用脚本“bin / jmeter”。您将注意到,“运行”菜单包含两个新的子菜单:“远程启动”和“远程停止”(见图1)。这些菜单包含您在属性文件中设置的客户端。使用远程启动和停止代替JMeter正常启动和停止菜单项。
图1 - 运行菜单
步骤3b:从非GUI客户端启动JMeter
GUI模式只能用于调试,作为一个更好的选择,您应该从非GUI(命令行)客户机启动远程服务器上的测试。这样做的命令是:
jmeter -n -t script.jmx -r
要么
jmeter -n -t script.jmx -R server1,server2,...
可能有用的其他标志:
-Gproperty =值
在所有服务器中定义一个属性(可能会出现多次)
-X
在测试结束时退出远程服务器。
第一个例子将开始测试JMeter属性remote_hosts中定义的任何服务器;
第二个例子将从服务器列表中定义remote_hosts,然后在远程服务器上启动测试。
当所有远程服务器停止时,命令行客户端将退出。
13.1手动操作
在某些情况下,jmeter-server脚本可能无法正常工作(如果您使用JMeter开发人员未预期的操作系统平台)。以下是如何通过更加手动的过程启动JMeter服务器(上述步骤1):
步骤1a:启动RMI注册表
自JMeter 2.3.1起,JMeter服务器启动RMI注册表,因此本部分在正常情况下不适用。要恢复以前的行为,请在服务器主机系统上定义JMeter属性server.rmi.create = false,然后按照以下说明进行操作。
JMeter使用远程方法调用(RMI)作为远程通信机制。因此,您需要运行JDK附带的RMI注册表应用程序(命名为“rmiregistry”),并位于“bin”目录中。运行rmiregistry之前,请确保您的系统类路径中包含以下jar:
- JMETER_HOME / lib / ext目录/ ApacheJMeter_core.jar
- JMETER_HOME / lib目录/ jorphan.jar
- JMETER_HOME / lib目录/ logkit-2.0.jar
rmiregistry应用程序需要访问某些JMeter类。没有参数运行rmiregistry。默认情况下,应用程序侦听端口1099。
步骤1b:启动JMeter服务器
一旦RMI注册表应用程序运行,启动JMeter服务器。使用jmeter启动脚本(“jmeter -s”)中的“-s”选项。
步骤2和3保持不变。
13.2 提示
JMeter / RMI需要从客户端到服务器的连接。这将使用您选择的端口,默认为1099。
JMeter / RMI还需要反向连接才能将服务器上的样本结果返回给客户端。
这将使用高端口。
此端口可以通过JMeter的属性来控制client.rmi.localport在jmeter.properties。
如果JMeter客户端和服务器之间有任何防火墙或其他网络过滤器,则需要确保它们被设置为允许连接通过。如有必要,请使用监控软件来显示正在生成的流量。
如果您正在运行Suse Linux,这些提示可能会有所帮助。默认安装可能会启用防火墙。在这种情况下,远程测试将无法正常工作。以下提示由Sergey Ten提供。
如果看到连接被拒绝,通过传递以下选项来打开调试。
rmiregistry -J-Dsun.rmi.log.debug = true \-J-Dsun.rmi.server.exceptionTrace = true \-J-Dsun.rmi.loader.logLevel = verbose \-J-Dsun.rmi.dgc.logLevel = verbose \-J-Dsun.rmi.transport.logLevel = verbose \-J-Dsun.rmi.transport.tcp.logLevel = verbose \
自JMeter 2.3.1起,RMI注册表由服务器启动;但是,这些选项仍然可以从JMeter命令行传入。例如:“jmeter -s -Dsun.rmi.loader.logLevel = verbose”(即省略-J前缀)。或者,可以在system.properties文件中定义属性。
该解决方案是从/ etc / hosts中删除127.0.0.1和127.0.0.2环回。如果127.0.0.2环回不可用,那么发生什么事情就是jmeter-server无法连接到rmiregistry。使用以下设置来解决问题。
更换
`dirname $ 0` / jmeter -s“$ @”
同
HOST =“ - Djava.rmi.server.hostname = [computer_name] [computer_domain] \-Djava.security.policy =`dirname $ 0` / [policy_file]“\`dirname $ 0` / jmeter $ HOST -s“$ @”
还要创建一个策略文件,并将[computer_name] [computer_domain]行添加到/ etc / hosts。
为了更好地支持用于远程测试的RMI通信通道的SSH隧道,因为JMeter 2.6:
- 可以设置一个新的属性“client.rmi.localport”来控制RemoteSampleListenerImpl使用的RMI端口
- 要使用本地机器上的端口,通过SSH隧道将隧道RMI流量作为远程端点,现在允许直接使用Java System Property“java.rmi.server.hostname”参数指定环回接口。
13.3使用不同的端口
默认情况下,JMeter使用标准RMI端口1099。可以改变这个。为了成功工作,以下所有需要同意:
- 在服务器上,使用新的端口号启动rmiregistry
- 在服务器上,启动JMeter,并定义属性server_port
- 在客户端上,更新remote_hosts属性以包括新的远程主机:端口设置
自Jmeter 2.1.1以来,jmeter-server脚本提供了更改端口的支持。例如,假设您要使用端口1664(也许已经使用了1099)。
在Windows上(在DOS框中)
C:\ JMETER> SET SERVER_PORT = 1664C:\ JMETER> JMETER-SERVER [其他选项]
在Unix上:
$ SERVER_PORT = 1664 jmeter-server [其他选项]
[N.B.使用大写环境变量]
在这两种情况下,脚本在指定的端口上启动rmiregistry,然后在服务器模式下启动JMeter,并定义了“server_port”属性。
所选端口将被登录到服务器jmeter.log文件中(rmiregistry不会创建日志文件)。
13.4使用不同的样本发送方
测试计划中的侦听器将其结果发送回客户端JMeter,将结果写入指定的文件默认情况下,样本将在生成时同步发回。这可能会影响服务器测试的最大吞吐量;必须在线程可以继续之前发送样本结果。有一些JMeter属性可以设置为改变此行为。
-
mode
采样发送模式 -自2.9以来,默认为StrippedBatch。这应该在客户端节点上设置。- Standard
一旦产生样本,就会同步发送样本 - Hold
保存数组中的样本,直到运行结束。这可能在服务器上使用大量内存,并且不鼓励。 - DiskStore
将样本存储在磁盘文件(在java.io.temp下),直到运行结束。序列化数据文件在JVM退出时被删除。 - StrippedDiskStore
从成功的示例中删除responseData,并使用DiskStore发送方发送它们。 - Batch
当计数(num_sample_threshold)或时间(time_threshold)超过阈值时发送保存的样本,此时样本将同步发送。可以使用以下属性在服务器上配置阈值:- num_sample_threshold
要累积的样本数,默认为100 - time_threshold
时间阈值,默认60000 ms = 60秒
另见Asynch模式,如下所述。
- num_sample_threshold
- Statistical
当计数或时间超过阈值时,发送摘要样本。样本由线程组名称和样本标签汇总。累积以下字段:- elapsed time
- latency
- bytes
- sample count
- error count
其他样本之间不同的变量将丢失。
- Stripped
从成功的样本中删除responseData - StrippedBatch
从成功的样本中删除responseData,并使用批生成器发送它们。 - Asynch
样本临时存储在本地队列中。单独的工作线程发送样本。但是,如果样本的创建速度比可以发送的速度快,则队列将最终填满,并且采样器线程将阻塞,直到某些样本从队列中排出。此模式对于平滑样本生成中的峰值非常有用。可以通过在服务器节点上设置JMeter属性asynch.batch.queue.size(默认为100)来调整队列大小。 - StrippedAsynch
从成功的样本中删除responseData,并使用Async发送方发送它们。 - Custom implementation
将mode参数设置为您的自定义样本发送者类名。这必须实现接口SampleSender并具有一个构造函数,该构造函数接受一个类型为RemoteSampleListener的单个参数。
- Standard
Stripped模式去掉responseData,这意味着依赖于以前的responseData可用的一些元素将不起作用。
这不是一个真正的问题,因为总是有更有效的方法来实现这个功能。
以下属性适用于批处理和统计模式:
num_sample_threshold
批次中的样品数(默认为100)
time_threshold
要等待的毫秒数(默认60秒)
13.5处理启动失败的节点
对于大规模测试,有一部分远程服务器将不可用或不可用。例如,当您使用自动化脚本分配许多云计算机并将其用作生成器时,由于云的问题,某些请求的计算机可能会启动失败。由于JMeter 2.13有新的属性来控制此行为。
首先,您可能想要的是重试初始化尝试,希望失败的节点稍微延迟启动。要启用重试,您应该将client.tries
属性设置为连接尝试次数。默认情况下只做一次尝试。要控制重试延迟,请将client.retries_delay
属性设置为在尝试之间休眠的毫秒数。
最后,您可能仍然希望使用那些成功初始化并跳过失败节点的生成器来运行测试。要启用它,请设置client.continue_on_fail = true
属性。