Apache Jmeter 分布式压测与监控，真那么难搞定？

1.前言

对于运维工程师来讲，须要对本身维护的服务器性能瓶颈了如指掌，好比我当前的架构每秒并发是多少，我服务器最大能接受的并发是多少，是什么致使个人性能有问题；若是当前架构快达到性能瓶颈了，是横向扩容性能提高大，仍是纵向扩容性能提高大。

若是须要了解这些信息，须要在两方面下功夫，一个是对服务器进行性能测试，一个是对服务器进行性能监控。

经过对服务器进行性能测试：咱们能够了解到当前架构的性能瓶颈，还能够对架构横向扩容和纵向扩容来进行测试，对后期的架构扩容提供数据参考。

经过对服务器进行性能监控：咱们能够了解当前服务器的CPU、内存、IO等资源是否耗尽，咱们能够在监控系统添加触发器，一旦服务器资源在快要达到瓶颈的时候，咱们能够触发一个报警让运维人员来处理，也能够触发一个让架构进行自动化扩容（若是是云平台，直接调用api建立主机，ansible部署应用和程序）

本文将介绍下，我在工做中使用jmeter测试性能瓶颈的一些实践。本文作性能测试适用于移动互联网架构，非移动互联网架构有其余更好的测试方法。

2.Jmeter分布式压测介绍

在工做中使用jmeter作大并发压力测试的场景下，单机受限内存、CPU、网络IO，会出现服务器压力尚未上去，可是压测服务器已经因为模拟的压力太大死机了。为了让jmeter工具提供更强大的负载能力，jmeter提供了多台机器同时产生负载的机制，下面是架构图。

原理：好比我在jmeter server配置线程数为10，循环次数为100，也就是会对测试服务器发起1000次请求，我有3台agent服务器，若是我在server端选择远程启动压力测试，那么每台agent都会对测试服务器发起10*100次请求，那么此次压力测试产生的请求就是10*100*3=3000次。

若是对原理不是很明白，看完下面的操做以后就会理解了。

3.Jmeter分布式压测环境搭建

3.1.搭建前说明

服务器环境说明：作性能测试能够直接在在云平台按需购买压力机，一旦测试结束释放压力机便可。

分布式环境压力服务器要求：

• 须要server（控制机）和agent（压力机），agent搭建在linux（centos 6.5）服务器环境下，server搭建在windows（server 2012）环境下。
• 压力测试瓶颈大都在带宽上面，须要保证压力机的带宽要比服务器的带宽高，否则压力上不去。
• 须要保证agent和server都在一个网络中，且在多网卡环境须要保证启动的网卡都在一个网段。
• 须要保证server和agent之间的时间同步。
• 关闭防火墙。

3.2.Windows部署jmeter

（1）部署jdk环境,配置path变量，安装完成效果以下

（2）直接去官网下载最新的二进制源码包便可。

（3）解压jmeter到指定目录，设置path变量，安装完成以后，在命令行运行jmeter命令，若是能够正常启动jmeter，说明环境配置ok。

3.3.Linux部署jmeter

（1）下载安装

wget http://mirrors.tuna.tsinghua.edu.cn/apache//jmeter/binaries/apache-jmeter-3.1.zip
unzip apache-jmeter-3.1.zip -d /usr/local/
cd /usr/local/
ln -s apache-jmeter-3.1/ jmeter

（2）配置启动脚本

#!/bin/bash
# chkconfig: 345 26 74
# description: jmeter agent
myip=`ifconfig eth0 |awk '/inet addr/{gsub(/addr:/,"");print $2}'`
cmd="/usr/local/jmeter/bin/jmeter-server -Djava.rmi.server.hostname=$myip"

start(){  
    $cmd &
}
stop(){
   jmeter_pid=`ps aux | grep jmeter-server | grep -v grep | awk '{print $2}'`    
    for pid in $jmeter_pid;do    
    kill -9 $pid         
    done
    }
    
    act=$1
    case $act in 
    'start')   
       start;; 
    'stop')   
       stop;; 
    'restart')   
       stop   
       sleep 2   
       start;;  
    *)   
      echo '[start|stop|restart]';;
    esac

（3）启动jmeter agent服务，验证是否监听1099端口

[root@jmeter-agent-01 ~]# /etc/init.d/jmeter-agent start
[root@jmeter-agent-01 ~]# netstat -lntp | grep 1099
tcp 0      0 0.0.0.0:1099        0.0.0.0:*      LISTEN 414/java

3.4.分布式环境配置

（1）确保server和agnet安装正确。

（2）Agent启动，并监听1099端口。

（3）在server机器的jmeter安装目录下bin目录下，找到properties文件，修改远程主机选项，添加3个agent服务器的地址。

（4）启动jmeter server，多网卡模式须要指定IP地址启动

jmeter -Djava.rmi.server.hostname=192.168.10.61

（5）验证分布式环境是否搭建成功

一、jmeter启动以后在以下选项中,会出现你添加的远程主机列表

二、建立一个请求测试：建立一个访问百度的请求，访问次数为一次，配置以下：

直接点击启动，是jmeter server机器发起一次请求，结果以下

请求全部以前的请求数据以后，在选择远程所有启动，查看发起的请求就是三次，也就是每一个agent服务器按照着server的配置，请求了一次。

若是你的环境在选择所有启动以后，没有报错，且发起请求数量和agent服务器数量一致，说明jmeter分布式压力测试环境搭建成功，能够进行测试了。

4.Jmeter断言

4.1.断言介绍

jmeter断言经常使用有两种，一种是响应断言，一种是响应时间断言，若是响应内容不知足断言的配置，则认为此次的请求是失败的。

响应断言：判断响应内容是否包含指定的字符信息，用于判断api接口返回内容是否正确。

响应时间断言：判断响应时间，是否超过预期的时间，用于判断api接口返回时间是否超过预期。

4.2.断言配置

（1）修改http为实际的api测试请求。

（2）断言添加方式：右击测试计划的http请求，选择添加à断言à添加响应断言和断言持续时间。

（3）配置响应断言：咱们接口正常返回code值为2000，若是接口返回code值不是2000表示接口异常，为了测试，这里修改成接口返回code值不为2222则表示访问失败。

（4）配置断言响应时间：设置请求接口时间超过1毫秒，则认为请求失败。

（5）验证断言配置：发起http请求，因为返回内容code值不为2222，以及访问时间超过1毫秒，因此认为访问失败。

5.Jmeter变量配置

使用变量的场景举例：咱们须要测试性能的曲线模型，也就是由轻压力慢慢变为重压力，来测试咱们的性能拐点，这个时候jmeter就须要配置多个线程组，每一个线程组须要设置http请求，好比下图；因为每次测试性能的曲线模型都是同一个接口，因此每次修改接口都须要修改http请求，这个时候若是使用了变量，就意味着每次修改api只须要修改api的变量便可。

设置变量的方法：在测试计划中

引用变量：

6.Jmeter性能测试结果分析

下面是我执行一次性能曲线模型测试（请求从每秒3千递增到3万）的聚合报告：简单的看下，能够看到性能的拐点在每秒发起2.7万请求，TPS处理能力能够达到6000每秒，99%的用户响应时间在60毫秒，最大响应时间为71毫秒，性能仍是不错的。

并发瓶颈：当请求从每秒2.7万递增到3万的过程当中，咱们的TPS由6000降低到了4500，能够看到并发瓶颈就在每秒最多处理6000请求

响应时间：咱们能够看到TPS保持在3500或之下，99%用户用户的响应时间为11毫秒，随着TPS的升高，咱们的响应时间也在随着升高，能够看到咱们的TPS在每秒3500响应的时候，对响应时间是没有影响的。

注意这个只是个人业务其中的一个接口，咱们生产有上百个接口，不一样的接口返回数据还有代码逻辑，以及执行的sql均不相同，若是须要作性能测试，应该选择其中的热点接口，对每一个接口进行性能测试，获得结果以后在进行具体的分析性能瓶颈到低是什么？

聚合报告参数说明：单位为毫秒

• Label：定义HTTP请求名称
• Samples：表示此次测试中发出了多少个请求
• Average：平均响应时长——默认状况下是单个request的平均响应时长
• Median：中位数，也就是50%用户的响应时长
• 90% Line：90%用户的响应时长
• Min：访问页面的最小响应时长
• Max：访问页面的最大响应时长
• Error%：错误请求的数量/请求的总数
• Throughput：默认状况下表示每秒完成的请求数（request per second）
• KB/Sec：每秒从服务器端接收到的数据量

7.测试中的监控

7.1.并发测试监控

并发测试直接发起指定数量的请求，好比一块儿发起10万请求看一下系统的处理能力，这个时候若是须要服务器的资源使用信息，就不能使用好比zabbix监控系统了，由于通常处理10万请求，对于咱们来讲20秒能够处理完毕，可是zabbix数据采集是每分钟一次，这样采集到的数据明显是不许的，这样就须要经过系统自带的监控命令，来实时查询服务器的性能，好比能够经过dstat或者glances等动态监控命令来分析系统的性能。

补充：不是测试每个接口都须要进行这样的实时监控，好比过测试个人大部分接口TPS可达5000，可是其中一个接口只能达到2000这个时候就须要在测试的时候实时监控，看一下究竟是什么缘由致使性能上不去。是因为返回数据太大致使网络带宽被占满；仍是sql执行时间太长致使数据库负载高，仍是代码有问题致使web服务cpu占用高。

7.2.稳定性测试监控

稳定性测试就是持续不断模拟指定数量请求，来访问服务器，好比我每秒向测试服务器发起4000请求，持续12小时，来看看服务器会出现什么状况，这个时候就须要用到zabbix来进行监控了，下面是我作性能测试的部分监控接口，包含tomcat每秒请求，服务器入口流量，整个集群每分钟请求的http状态码统计，还有服务器资源使用信息。

欢迎你们关注个人微信公众号【民工哥技术之路】，最新整理的 2TB 技术干货：包括架构师实战教程、大数据、Docker容器、系统运维、数据库、redis、MogoDB、电子书、Java基础课程、Java实战项目、ELK Stack、机器学习、BAT面试精讲视频等。只需在「 民工哥技术之路」微信公众号对话框回复关键字：1024便可获取所有资料。