jmeter简单压测

使用jmeter进行bbs压测

1. 压测的目的及准备
2. 业务分析
3. 脚本编写
4. 压测结果
5. 曲线图
6. 遇到的问题

一、压测目的及准备
目的：

为了提高论坛评论接口的稳定替换，针对系统中的关键业务点：发表评论、点赞、回复、主题更新、批量获取主题信息等模块的性能测试。
根据实际的性能监控数据进行最大的负载指标进行调优，达到性能要求。

准备
接口文档：（内部地址，见谅）
压测工具：jmeter5.2.1
测试环境：4核8G
线上环境：16核32G
JM脚本编写分析

二、业务分析

评论接口要功能：
1、发表评论
2、评论点赞
3、获取评论内容
4、获取详情及回复列表
5、获取页面主题的评论信息
6、批量获取业务主题评论数
7、获取主题详情
8、获取评论列表

通过以上接口模块进行分析，使用jmeter5.2.1，模拟用户并发操作。
1、对单个模块进行压力测试，模拟并发，确保单模块并发通过。
2、测试系统发表评论、点赞在多用户同时进行发表及点赞的可能性，模拟多用户同时点击发布。
3、获取评论内容及回复、获取详情及回复列表、批量获取业务主题评论数等，模拟用户同时进入主题，进行批量查询操作，设置多用户并发、循环查询数据。
4、模拟对接专题及口碑等接口的调用频繁获取主题信息。

三、脚本编写

1、创建线程，创建8个线程（由于需要是单独模块对接故先不做多线程联调）
跟正常的使用JM一样，配置头、线程组等需要的配置

2、对每个线程组进行对应参数的配置（根据接口文档进行需要的参数配置，其中变量根据分析进行模拟）
以发表评论为例，对一个主题文章进行不同用户的随机发送数据这里用到参数化助手，读取本地设置好的csv文件中的userID，JM会按照列的顺序去读取（函数助手__CSVRead）然后设置随机发送的数据（函数助手__Radom,这个可以进行一定范围内的，随机抽取内容)

3、创建完成之后，进行脚本的执行，其他模块可进行对应参数的配置，不做累述
模拟100个用户不间断的进行查询数据，在线程组中设置100个线程数，间隔时间模拟用户发送最快的时间，这里设置的1s，循环设置永远，持续时间根据具体业务来定，这里选择的是60s
>>
4、创建查看结果数、聚合报告（这里要注意的是MAC版的jm需要单独装插件，可自行百度，按照正常的逻辑应该在脚本中加入断言，由于时间比较紧加上接口文档比较细致，所有的报错都有明确的code，所以就么有写断言，测试小伙伴一定记得写断言哦！）

四、压测结果

分别对接口进行20、50、100进行 1min内的不间断的并发，结果汇总下表

构建曲线图，分析结果

根据上图曲线图可得出初步结论：
1、发表评论，未达到瓶颈，压测已到预期
PS：发表评论用到了消息队列进行了异步消息处理，故接口消息发出，MQ中的消息处理较缓慢，原因测试环境数据库处理慢，导致MQ消费速度下降（后期考虑单独压测MQ）
2、评论点赞、获取评论内容/回复内容、批量获取业务主题评论数、获取主题详情，模拟100用户在1分钟内的每秒频繁评论，其中线上还会对每个id进行发布间隔限制，因此可满足现有需求
3、获取详情及回复列表、获取页面主题评论信息和获取评论列表由于含有论坛接口，模拟100用户未达到瓶颈，服务器性能不太稳定，需要排查原因后进行测试已告知开发
4、因测试服务器与线上服务器配置不同，以上测试结果供参考使用

遇到的问题
1、在执行脚本的时候，发现即使并发不高的时候也会出现错误，而且错误数量极低（0.01%），后台及nginx外层错误日志，结果树中也没有错误的请求，最后排查到工具本身是否有问题，拉取了jm的log日志（mac版的JM显示与win有差异，只能查看log）发现jm有报错：non http responsecode:org.apache.http.connectionclosedexception，通过查询发现，在使用JM的时候，根据请求和环境的不同，并发量不大的情况下会出现这种报错,需要修改implementation参数属性，不修改属性前，implementation是空的，修改为JAVA ，运行后发现工具这种报错消失， 压测数据均正常了；具体implementation的设置如下：
Java：使用的http是使用的JAVA JVM提供的方法
HTTPClient3.1：使用Apache HttpClient3.1部件，已不再开发了，在jmeter以后的版本中可能会不使用
HttpClient4.1：使用Apache HttpClient 4.1部件
空白：使用HTTP默认请求中的配置或jmeter.properties中jmeter.httpsample中的配置若不对参数URL编码则需要选择implementation为java；若想不设implementation值，则需进行参数URL进行编码

2、本次测试，开发对发布评论使用MQ消息队列，对消息进行了异步通信，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。

MQ的优点：解耦、异步、削峰，可以大大降低请求资源对于系统以及数据库的压力。
MQ弊端：
1、如果消费能力比较慢的时候，这时候队列中有几万甚至更多的数据，突然MQ挂掉的话，那么没有走完的消息都会造成很大影响
2、可能会出现重复消费的情况，或者消息传递的顺序错误
3、MQ虽然可以提升整体的系统性能，但是如果存在多个系统，接口这直接返回成功，到达另一个系统或别的系统开始进行写入数据，但是这边还没有消费完，这样会造成数据的不一致性
具体的MQ原理自行百度，后期压测MQ在进行补充