压测必经之路,解读JMeter分布式

发表于:2019-7-18 08:08  作者:王练   来源:51Testing软件测试网原创

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 软件测试工具 Jmeter

  摘要:JMeter是当前Web性能测试中应用最为广泛的工具,简洁强大的界面,开源免费的授权,以及广泛的插件扩展,使得JMeter能满足几乎所有Web场景的性能测试。然而,单机性能的限制,是JMeter一直以来最大的诟病。由于采用Java多线程进行并发用户的模拟,使得线程数的增加自然增加了测试机的资源消耗。一边是被测系统并发数的日益提高,一边是JMeter单机性能的掣肘。测试人员仿佛是走钢丝的杂技演员,平衡木的一边是并发数,一边是测试机的资源,战战兢兢、小心谨慎的想找到其中的平衡。
  实际上JMeter提供了一种分布式压测的方法提高并发能力。本文介绍如何配置一个JMeter的分布式测试环境,并对单机和分布式的测试机资源占用情况进行对比。最后,对分布式的线程数、并发机制以及影响分布式TPS的采样信息回送模式进行说明。
  一、引入JMeter分布式
  JMeter是Web性能测试中的利器,基本属于Web压测的事实标准。然而使用过JMeter的测试人员会发现,当并发用户增加后,JMeter本身的性能也会急剧下降,导致无法对被测系统施加压力。
  以一个实际环境为例,系统配置为:Windows 7旗舰版,i5-4590单CPU4核4线程,4G内存。使用JMeter3.1,Java8进行测试。
  当并发线程设置为1000时,资源占用如下图。
  继续增加线程个数为1500,此时运行出现错误如下。
  查看日志中的记录,可以看到由于内存不足,无法启动新的线程。
  如果我们需要更多的线程并发,此时就必须使用JMeter的分布式压测了。
  二、环境搭建
  遵照JMeter官网的方法,很容易搭建适合自己需要的分布式环境。以下图的实际环境为例,测试机A作为压测的协调主机(即上述的机器),B和C作为执行机,实际完成压力的发送,被测系统位于D上。
  具体配置过程如下:
  1、执行机属性配置。配置执行机RMI服务的端口,修改\apache-jmeter-3.1\bin下的jmeter.properties,将如下属性修改为指定的端口:server_port和server.rmi.localport。本例中B均修改为1039,C均修改为1058。如下图:
  2、启动执行机的监听服务。在执行机上启动服务,打开\apache-jmeter-3.1\bin下的jmeter-server.bat即可。启动图如下。

  说明在B的1039端口,C的1058端口均启动了执行的服务,等待协调主机的命令。
  3、协调主机属性配置。配置协调主机连接的执行机和端口,修改\apache-jmeter-3.1\bin下的jmeter.properties,将remote_hosts属性修改为需要连接的执行机IP和端口。如下图。
  4、执行测试。启动协调主机的JMeter,通过界面进行启动。
  如上图,通过Run->Remote Start可以启动单个执行机,通过Remote Start All启动全部执行机。
  3、资源对比
  在前面我们看到,单台如上配置的测试机在启动1500线程时会出现内存不够用的情况。那么分布式的情况如何呢?
  下图为协调主机的资源占用情况。
  其中一台执行机的资源占用情况,执行机B,Windows10 教育版,i5-6500单CPU4核心4线程(3.20GHz),8G内存。
  另外一台执行机的资源占用情况,执行机C,配置为Windows Server 2012 R2 Standard,Intel Xeon单CPU6核12线程。
  4、注意事项
  通过JMeter分布式进行压测,可以避免单机测试机资源的限制,提高压测的并发线程数。然而,还有一些细节需要注意。
  1、线程数。JMeter分布式测试,是通过网络连接将协调主机载入的脚本分别传递(复制)给执行机,也就是说每个执行机拿到的脚本都是一致的,所以在每台执行机都会启动脚本中线程组指定的并发线程数。这样在设定脚本线程数目时,需要除以执行机个数,设定并发线程数。
  以上述示例进行说明,期望完成1500用户并发,在单机测试时脚本设置并发线程为1500,而在有两条执行机的情况下需要设定为750,脚本修改如下。
  此时启动远程测试Remote Start All后,看到界面的显示如下。
  其中的1500/0,含义是一共启动了1500个线程,本机为0。
  2、同步定时器的使用。我们知道,同步定时器(Synchronizing Timer)的意义在于提供瞬间压力的测试,其原理是阻塞期望个数的线程(用户),在同时进行释放,尽可能真实的模拟并发用户同时进行某操作的情况。那么在分布式并发的情况是如何的呢?我们将上述例子简化为20用户并发,即每个执行机10个线程,同时增加一个同步定时器,期望15个线程瞬间压测。脚本修改如下。
  执行远程测试Remote Start All,监控结果树的情况。会发现没有任何请求被发送。这是因为,同步定时器仅在一个JVM中起作用,而分布式环境下属于两台机器的两个独立JVM,同步定时器无法生效。此时对于每个执行机,均启动了10个线程,但获得的脚本中需要等待20个线程再释放,所以两个执行机均不会向下执行。
  JMeter官网原文如上,含义就是同步定时器阻塞线程的机制仅在一个JVM中,所以在分布式的情况下,设定的阻塞线程数不能超过每个执行机的并发线程数。本例中就是不能超过10线程。
  类似的,高斯随机定时器(Gaussian Random Timer),固定定时器(Constant Timer),均匀随机定时器(Uniform Random Timer),泊松随机定时器(Poisson Random Timer),BeanShell定时器,BSF定时器,JSR定时器。由于是针对单线程的,所以不受分布式的影响。
  当然,吞吐量定时器也是对于每个执行机独立进行限制的。也就是说,设置的吞吐量限定值,由于脚本是分别在每个执行机进行运行的,所以限定的也都是当前作用的执行机。
  3、执行机测试结果回送方式。JMeter分布式的原理十分容易理解,在实际测试中就如同蝴蝶效应一样,一点细微的差别都会导致最终加压结果的巨大差异,从而导致最终测试结果的不确定性。在分布式测试中,执行机测试结果的回送方式影响非常大。
  首先我们对比一下实际的测试结果。在协调主机和执行机上的配置文件\apache-jmeter-3.1\bin下的jmeter.propertie中,修改mode=StrippedBatch,如下截图。
  注意在协调主机和执行机上均要修改。运行测试,此时我们查看协调主机的网络使用率和测试的TPS,可以发现对于百兆网卡使用了其中7%的流量,对于被测系统的TPS为461。
  此时查看其中一个执行机的网络使用情况,也在可以接收的范围内。
  接下来,修改mode=Standard,进行同样的测试。观察协调主机的测试结果如下。
  可以看到100M网卡已经被消耗殆尽,使用率达到97.3%,而TPS也只有92,可以想象,此时对被测系统压力是非常有限的。同样的,可以看到执行机的网络使用情况如下。
  对比之前的结果,也是让人堪忧的。可以想象,以这样的测试环境对被测系统进行测试,得到的测试结果能有多大的可信度。

  ......
查看更多精彩内容,请点击下载:

版权声明:本文出自《51测试天地》第五十四期。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像,否则将追究法律责任。

21/212>

评 论

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海信义律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2021, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道