JMeter压力测试后端服务

﹏ヽ暗。殇╰゛Y 2023-06-13 06:05 135阅读 0赞

# 背景 #

需要验证后端埋点方案是否满足业务服务接口的性能要求：

延时：200ms (tp95)，QPS：2000。

有大概三台服务器。

# 埋点方案 #

logback发送日志到kafka，ack=1（partition leader ack了就算发送成功）

所以我们的希望是logback写日志的过程对业务服务性能几乎无影响。

# 分析 #

200ms (tp95)：即95%的请求可以在200ms能响应完成。一秒内可响应5次请求。

QPS：2000：即在峰值到来时，高并发下，可以一秒可处理2000次请求。

综上，可以反推出整个服务大概可以应对400的并发。有三台服务器，所以均衡一下，每台服务器要扛700的qps、140的并发。

# 验证方案 #

1.springboot配置logback，ack=1

2.开发一个接口，忽略业务逻辑（因为还没开发完），只有一行代码，写一条日志。

3.jmeter配置压测方案，配置线程140个，每个线程发送1000次，如何模拟qps=700呢，jmeter提供了常数吞吐量定时器，即以固定吞吐量发送请求，在目标吞吐量上填42000（为啥是42000稍后介绍），选择基于“所有活动线程”计算吞吐量。同时添加聚合报告，聚合报告可以查看压测结果。

4.将springboot的jar包部署在远程服务器上，本地开启jmeter执行压测方案。（如果你是在windows上开启的jmeter需要把本机的端口上限调大，端口回收时间调短，不然测试一会儿就会发现本地的端口耗尽了）

# 验证结果展示 #

点击jmeter的聚合报告，显示如下

![20191114133337540.png][]

发送了140\*1000次请求，平均响应时间为140毫秒，95%的请求在150毫秒内就返回了，吞吐量接近700。咋看性能符合要求。

# 如何以固定吞吐量压测 #

即上文中的42000怎么来的。jmeter的常数吞吐量定时器，是一个以常数（42000）吞吐量来压测的。这个常数是分钟计算的。之前计算过，单机应对140的并发，每秒处理5个任务，那就是意味着qps=140\*5=700，qps指的是每秒处理700个任务，那每分钟就是42000个任务。所以在配置常数吞吐量定时器时，目标吞吐量要设置为42000，这个吞吐量是基于140个活动线程计算出来的。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hhb2hhaXppamh6_size_16_color_FFFFFF_t_70][]

通过线程模拟了并发，如果程序性能满足要求，吞吐量qps就会接近700；如果性能不好，虽然jmeter设置了目标吞吐量，但实际测试时实际的吞吐量就可能不会这么高，延迟也会加大。

# 再审视 #

回看我们的第一张图，再审视一下，是否满足性能要求呢？看结果是不太理想的，因为单写个日志就耗费150ms，如果再加上业务逻辑，再访问个es或者关系数据库，肯定会超过200ms这个性能要求的。

真的是写日志就耗费了150ms么，再测一下，发现更慢了超过了200ms。那把写日志的那一行代码注释掉。再测，依然慢。。

why

难道是我的springboot工程有问题，用浏览器看一下，也很慢。开个网页也慢！

这个时候可以怀疑网络环境了，ping一下远程服务器ip和百度ip，果然网络环境不好。本地开发机访问不了kafka，所以我们只能在远程服务器上部署jmeter了。

# Linux上开启Jmeter #

安装，直接解压缩就能用。

开启压测只需一条命令：

jmeter -n -t test.jmx -l test.jtl

test.jmx是jmeter测试计划配置文件，test.jtl是测试结果。jmx文件可以直接从带UI的操作系统上拷贝过来。生成的结果文件test.jtl可以导入带UI的操作系统，方便统计和查看。

Jmeter在Linux上的运行截图（其实不用再导入jtl文件直接看命令行输出也可以看出个大概）

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hhb2hhaXppamh6_size_16_color_FFFFFF_t_70 1][]

可以去用kafka查看一下topic里最新的消息有没有写入

kafka-console-consumer.sh --bootstrap-server 'ip1:9092,ip2:9092,...' --topic bigdata_webservice_test

top看下CPU和内存消耗

![20191114142321979.png][]

jps看下对应的程序

![20191114142456300.png][]

313 jmeter的进程、22313 springboot的进程、32303 kafka的进程（在查看生产者发送的消息）

Jmeter导入jtl文件，首先要有一个带聚合报告的测试计划，然后导入文件就能得出统计结果。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hhb2hhaXppamh6_size_16_color_FFFFFF_t_70 2][]

把上文生成的jtl文件导入JMeter后，可以查看到如下结果：

![20191114153537108.png][]

备注：本地压测发现：接口中在没有业务逻辑、只写埋点日志的情况下，99%的请求1ms内就会响应，几乎没有存在感，不会影响整个业务接口的响应性能。之前测试时，受网络环境影响，大部分时间消耗在网络传输上了。

# Tips: #

Jmeter需要你在执行压测前，先清空一下历史记录，不然聚合报告会叠加之前的历史。

![20191114141548335.png][]

[20191114133337540.png]: https://img-blog.csdnimg.cn/20191114133337540.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hhb2hhaXppamh6_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20191114134236430.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hhb2hhaXppamh6,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hhb2hhaXppamh6_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20191114142208970.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hhb2hhaXppamh6,size_16,color_FFFFFF,t_70
[20191114142321979.png]: https://img-blog.csdnimg.cn/20191114142321979.png
[20191114142456300.png]: https://img-blog.csdnimg.cn/20191114142456300.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hhb2hhaXppamh6_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20191114141346677.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hhb2hhaXppamh6,size_16,color_FFFFFF,t_70
[20191114153537108.png]: https://img-blog.csdnimg.cn/20191114153537108.png
[20191114141548335.png]: https://img-blog.csdnimg.cn/20191114141548335.png