vlambda博客
学习文章列表

运行稳定且满足大部分性能测试场景的工具居然是它?!


摘要: 通过自动化测试工具模拟正常、异常场景来对系统的各项性能指标进行性能测试可以分析一个系统能力、瓶颈、关键问题等,本文结合nGrinder工具的特点,主要介绍了nGrinder在性能测试过程中的应用。

运行稳定且满足大部分性能测试场景的工具居然是它?!
一、性能测试工具

  性能测试范围较广,负载与压力测试都属于性能测试,两者可以相结合进行测试。 通过逐渐增加负载根据系统资源的变化情况,可找到系统瓶颈所在,通过压力测试能确定系统的最大服务级别,一般系统上线前均会进行性能测试。 本文使用nGrinder作为性能测试工具,直接部署成web服务,通过对不同场景进行测试,确定系统瓶颈及系统最大服务级别。


运行稳定且满足大部分性能测试场景的工具居然是它?!
二、nGrinder安装

    2.1.安装Controller
  从nGrinder官网下载nGrinder-controller-3.4.1.war,将nGrinder-controller-3.4.1.war放入tomcat的webapps目录下,启动tomcat,使用http://host:port/nGrinder-controller-3.4.1/ 进入登录界面。 也可以使用jar启动该web服务,jdk1.7使用java  -jar -XX: MaxPerSize=200m -jar nGrinder-controller-3.4.1.war,jdk1.8不指定 MaxPerSize参数; java启动方式使用http://host:port/login进入登录界面,初始账号密码均为admin。
   2.2.运行代理
  解压nGrinder-agent.rar,解压后nGrinder-agent目录下的__agent.conf为配置文件,可根据实际情况进行修改。

common.start_mode=agent

agent.controller_host=127.0.0.1

agent.controller_port=16001

  其中common.start_mode为启动模式可选择agent模式和monitor模式,做为agent使用时,配置成agent,agent.controller_host配置为controller机器的ip地址,agent.controller_port端口默认为16001,不需要修改。
  Linix系统下运行run_agent_bg.sh,windows下运行run_agent.bat,即可启动nGrinder的agent,登陆后选择admin->agent Management即可看到刚才配置好的agent机器信息。
运行稳定且满足大部分性能测试场景的工具居然是它?!
  可通过Disapproved设置agent是否可用。
  1)nGrinder可以通过添加用户的方式进行压力测试,测试过程中出现使用新建用户agent不能使用的情况,通过登陆该用户,Download Agent下载agent并重新启动该agent解决了该问题。
  2)在压测过程中出现修改agent文件夹__agent.conf的配置后controller端看不到该agent的情况,经分析是由于nGrinder的agnet在启动时会默认在当前用户的根目录下建立.ngrinder_agent的文件夹,下次启动时会默认使用该文件夹中的配置文件agent.conf启动,直接删除该文件即可快速解决。
   2.3.运行监控
   解压nGrinder-monitor-3.4.1.tar到要监控的机器上,解压后nGrinder-agent目录下的__agent.conf为配置文件,可根据实际情况进行修改。 Linux 系统运行run_monitor_bg.sh,windows下运行run_monitor.bat即可启动monitor。

运行稳定且满足大部分性能测试场景的工具居然是它?!
三、不同场景下的测试解决方案

   3.1登录接口的tps
  测试过程中需要对平台登陆能力进行压测,接口使用Http请求,接口请求报文样例: POST http://*****/pushmsg.do?device_token=XXX&,我们通过开发对应的jar包,通过引入包的方式编写测试脚本,nGrinder.test下的HttpClient实现客户端发送get及post的http请求,通过导出jar包的方式导出HttpClient包,注意导出jar的时候的使用的Java的版本需要跟tomcat使用java的版本匹配,通过script->Create a folder,创建lib文件夹,将生成的jar包上传至该文件夹下。
运行稳定且满足大部分性能测试场景的工具居然是它?!
  在引用类的位置加入引用import nGrinder.test.HttpClient;使用时直接在使用位置String result = HttpClient.doPost("XXXX","XXXX"),适合Java脚本开发,在编辑脚本处的Validate Script可验证当前脚本。
  点击“Performance Test”,创建测试,输入名称、代理、用户数、执行时间等参数,选择刚才创建的脚本,点击“保存并运行”。 设置时需要将要测试的目的ip地址填入Targer Host中,否则在测试结果没有测试服务器的监控数据。
运行稳定且满足大部分性能测试场景的工具居然是它?!
  测试过程中会实时显示测试服务器与压测服务器的CPU使用率及内存使用率,方便实时查看。
运行稳定且满足大部分性能测试场景的工具居然是它?!
  从测试结果看,压测的tps为26,在测试过程中发现cpu达到了100%,由于agent、controller、monitor在同一台机器上,CPU存在瓶颈,agent、controller、monitor分别部署测试效果更明显,测试完成后可查看agent的日志及监控数据,windows系统的默认目录在C:/User/用户名/.nGrinder下,包含日志、配置、测试案例、资源、脚本等,监控测试案例数据在perftest/0_999/测试案例号,本案例为324,则在324文件目录下,report目录为所有测试数据,可根据实际需要进行二次开发。
   3.2同时在线能力
  单台服务器支持长连接数是系统性能指标之一,在该场景中我们解决的问题有:
  测试过程中,由于机器有限在一台机器部署多个,启动时拷贝了一个相同agent文件,启动时指定agent的名称及根目录位置使用 ./run_agent.sh -o -ah ~/ngrinder-agent --host-id  first-agent,./run_agent.sh -o -ah ~/ngrinder-agent2 --host-id  second-agent启动2个agent。
运行稳定且满足大部分性能测试场景的工具居然是它?!
  测试过程中,使用的agent机器为Suse linuxt虚拟机器8c16g及4c8g,部分机器在agent启动过程中报错Failed to instantiate [ch.qos.logback.classic.LoggerContext]
  Reported exception: sun.misc.ServiceConfigurationError: sun.net.spi.nameservice.NameServiceDescriptor: Provider org.ngrinder.dns.LocalManagedDnsDescriptor could not be instantiated: java.lang.ExceptionInInitializerError,经查阅资料发现nGrinder必须通过DNS解析一次,即使解析不到也需要一个DNS Server,优先走DNS,不走本地的/etc/hosts解析,我们通过在/etc/resolv.conf中增加 nameserver 127.0.0.1解决。
  在测试过程中,某些agent报错too many open filesXXX,这个问题主要是进程企图打开句柄,但是现在进程打开的句柄数已经达到上限了,我们调整/etc/security/limits.conf,增加* soft nofile 1000000、* hard nofile 1000000解决了该问题。
  某些agent的只能达到28000的连接数,一直维持到28000,经分析该问题是由于使用的agent机器为虚拟机,该虚拟网卡可打开的端口最大为65535个,修改程序可打开的ip地址范围/proc/sys/net/ipv4/ip_local_port_range为5000 65535,使单台agent支持的最大连接数达到60000。
  测试过程中还出现了 Name or service not known at java.net.Unknown Host Exception: host-10-XX: host-XX: Name or service not known,主机名称由vl-49064692851改为了host-XX,需要在 /etc/hosts下添加服务器ip地址 host-XX。

运行稳定且满足大部分性能测试场景的工具居然是它?!
四、结论

  使用开源性能测试工具nGrinder进行性能测试,当使用lib库内容较大时,由于nGrinder本身设计的原因,需要将lib库文件及对应的资源文件、脚分发到agent上,agent从启动到真正进行发压时间较长,同时nGrinder在计数上存在一些问题,对于只有放在Test里面的内容才能计算tps,对于逻辑复杂的过程,在计算tps上显得有些不足,我们通过开发一个接收工具,该工具可以统计接收的tps,通过小工具弥补nGrinder工具的不足,虽然nGrinder工具有缺陷,但相对于收费的Loadrunner,编程能力不强的JMeter已经满足了大部分性能测试场景,工具在使用过程中表现稳定。




运行稳定且满足大部分性能测试场景的工具居然是它?!
END



运行稳定且满足大部分性能测试场景的工具居然是它?!

推荐阅读

点击阅读☞

点击阅读☞

点击阅读☞

点击阅读☞

点击阅读☞

“阅读原文”一起来充电吧!