使用apache jmeter进行压力测试
前言
一个系统开发完成，上线的前夕,是需要进行各种测试，以确保质量过关。其中压力测试是必不可少的一环。
当前公司项目临近上线，领导让我做下压力测试，是否能负载业务的并发要求。
这里记录一下过程。
问题
如何进行压力测试？
思路：
压力测试本质是模拟请求(用户)，不断尝试对系统进行读写,查看系统是否能正常运行。
压力测试需要借助工具完成，部分复杂的测试，还需要自己编写脚本。
由于我们测试要求比较简单，这里直接选择现成的工具。
我选择的是apache jmeter
测试过程
-
部署系统。
你需要对哪个系统进行压力测试，需要部署好,确保web可以访问。
这里由于我存在2套环境，一套测试，一套生产。部署在不同性能的服务器上，测试环境的机器比较差，没有压测的必要。我们项目还未投入生产，没有用户使用，测试产生的数据也可以随意删除。所以可以直接对生产环境的进行测试。
如果你们的系统已经投入生产，存在用户访问，这里压测的话要三思。千万别影响正常的用户访问或者导致生产数据库的破坏。 -
确定要测试哪些请求。
正常的一个系统有无数个请求,不可能全部测试。这里压力测试应当选择最能代表性的请求。
例如活动的主页面、创建订单页面等。这些请求是实际应用中访问量最大，同时也是最重要的。需要确保不能崩溃。
根据我的实际情况，我这里选择的是测试 心跳请求和 整点电量上报请求。该请求符合上面的特征。
-
下载压力测试的工具。
image.png
解压之后。进入bin目录。双击 apacheJmeter.jar 运行。
image.png
运行后的界面如下：
image.png
点击 options - choose language - chinese 。进入中文界面。
image.png
- 配置测试计划
这里依次创建：创建计划、添加线程组、添加HTTP信息头管理器、添加HTTP请求默认值、心跳请求、聚合报告、图形结果。
中文界面下，名词应该可以直接从字面意思理解。就不截图一一解释了。
这里提供一份测试计划。直接通过菜单栏 file open 即可得到一个计划。
链接: https://pan.baidu.com/s/1n2-OMYEQFmcUJ-NbqQZwZQ 密码: 2xwh
下载后解压得到一个jmx后缀的文件。通过file -》 open 选择该文件即可
注意：需要修改下服务器地址和传递参数。
要注意一个细节：点击绿色按钮运行，是运行整个测试计划,下属的所有线程组都会运行。如果需要只运行其中一个线程组，应该右击该线程组，选择start
我悲剧了，配置多个线程组，每个线程组都分配了N多线程。结果点击了绿色按钮，全部执行。导致服务器之间崩溃。电脑卡死。
修改用户的数量。
image.png
-
点击启动
image.png
查看测试产生的结果。例如请求的耗时、请求是否异常。
这里我只关心请求是否异常。如果没异常，继续增加用户数量。直到出现异常。
每次运行都会产生一些结果。如果不清理，会一直保留,影响判断。这里可以选择菜单栏：运行-清理
- 查看测试时服务器的资源消耗。
服务器使用的centos7
可以使用top语句。查看变化。以确保是否存在cpu和内存问题。
top
image.png
由于我的项目运行在docker里。所以我这里使用的命令如下
docker stats lightai-web_tomcat_1
image.png
这里要注意，如果你使用的docker，则 cpu 100%代表的是使用了1个cpu 而不是满负荷的意思。我一开始以为是cpu爆了。其实不是。可以800% 因为我这里是8核。
- 解决压测发现的问题。
压测的时候，通常会发现一些问题。例如请求报错。
image.png
-
如何解决。
-
根据请求的错误反馈结果直接判断问题。例如请求的响应中直接是java异常。那直接去定位到问题，修复异常。
-
根据程序执行请求的流程，依次查看日志文件。
一般的项目请求都应该是直接到nginx代理-再转发给tomcat-再访问数据库。
因此应该nginx日志、tomcat日志、mysql日志。 -
案例分析
这里提供几个我遇到的问题和解决过程
- nginx引发的问题。
压力测试异常后，我在在nginx的日志里查看到如下结果：
2018/06/27 15:19:44 [alert] 7#7: 1024 worker_connections are not enough
2018/06/27 15:19:44 [alert] 7#7: 1024 worker_connections are not enough
2018/06/27 15:19:44 [alert] 7#7: 1024 worker_connections are not enough
2018/06/27 15:19:44 [alert] 7#7: 1024 worker_connections are not enough
2018/06/27 15:19:44 [alert] 7#7: 1024 worker_connections are not enough
2018/06/27 15:19:44 [alert] 7#7: 1024 worker_connections are not enough
2018/06/27 15:19:44 [alert] 7#7: 1024 worker_connections are not enough
2018/06/27 15:19:44 [alert] 7#7: 1024 worker_connections are not enough
修改nginx的配置中的参数即可，将1024修改为10240
events {
worker_connections 10240;
}
- 数据库数据库引发的问题。
压测异常后,在tomcat的执行日志中发现如下内容
UPDATE `warns` SET status=?, gmt_modified=? WHERE 1=1 AND client_name = ? AND client_type = ? AND warn_type = ?
### Cause: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Lock wait timeout exceeded; try restarting transaction
; SQL []; Lock wait timeout exceeded; try restarting transaction; nested exception is com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Lock wait timeout exceeded; try restarting transaction
at org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.doTranslate(SQLErrorCodeSQLExceptionTranslator.java:259)
at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:73)
at org.mybatis.spring.MyBatisExceptionTranslator.translateExceptionIfPossible(MyBatisExceptionTranslator.java:75)
at org.mybatis.spring.SqlSessionTemplate$SqlSessionInterceptor.invoke(SqlSessionTemplate.java:447)
at com.sun.proxy.$Proxy15.update(Unknown Source)
at org.mybatis.spring.SqlSessionTemplate.update(SqlSessionTemplate.java:295)
初步判断数据库连接的时候，sql执行等待锁，需要去数据库进一步去确定问题。
连接mysql，进入information_schema库的INNODB_TRX表
该表会记录哪些sql语句在等待执行中和等待锁。
image.png
解决方法：
1、表设置为 InnoDB 。该引擎会使用 行锁，在数据频繁更新的情况下,效果更优秀。
2、增加索引。这里应当将 client_name 、 client_type 、warn_type 组成联合索引。
image.png
3、优化程序。确保该测试请求中是否必须进行update操作？ 最终我删除了这个update操作。
4、测试请求的设计错误。我这里出现问题的本质原因是我发送的请求都是操作相同的一条的数据。10000个并发修改同一条数据，必然出现死锁。
- 测试机器的网络环境。
有的时候测试发现，出现网络异常。可能是当前测试机器网络状况不佳。最好确保当前运行jmeter工具的机器网络状况。
再解决如上3个问题后，我的压测提高到了2000并发。已经满足我的需要了。
最后
压测最终得到系统能承受的范围。这里可能还需要考虑如何避免系统被冲垮。
可以通过nginx的 ngx_http_limit_conn_module模块进行设置。
有2种限制策略。这里不做细究。
limit_req_zone 用来限制单位时间内的请求数，即速率限制,采用的漏桶算法 "leaky bucket"
limit_req_conn 用来限制同一时间连接数，即并发限制
