首发链接:https://chen-yijie.blogspot.com/2018/10/jmeter.html
学习Jmeter对API接口进行压力测试
仍然以WeChatTicket为例
测试抢票接口
服务端接收微信消息的路由为/wechat，消息格式为XML
配置服务端忽略微信消息校验，即任何客户端都可以发起连接
抢票逻辑是处理用户发来的文本信息，消息字段如下，进行压力测试时，我们也需要模拟以下消息体
< ![CDATA[toUser] ]>< ![CDATA[fromUser] ]>1348831860< ![CDATA[text] ]>< ![CDATA[thisisatest] ]>1234567890123456
测试方法:
利用脚本事先在wechat_user数据表里生成已经绑定好的测试用户，将其用户的open_id全部保存在csv文件里
设置测试计划，Jmeter项目结构如下:
- 测试计划
- CSV数据文件设置
- 线程组
- HTTP请求
- HTTP信息头管理器
- BeanShell PostProcessor
- 查看结果树
- 汇总报告
每一项的关键设置:
CSV数据文件设置:读取用户open_id到变量中
线程组设置合适的并发线程数与Up-time,指定永远循环
HTTP请求的消息体数据直接按上述XML格式填写，用户open_id(fromUser)用之前的变量替换即可
HTTP信息头管理器:设置请求头Content-type=text/xml(不知道有没有必要)
BeanShell PostProcessor填写prev.setDataEncoding("UTF-8");，正确设置显示返回数据的编码(参考自http://blog.51cto.com/ydhome/1864340)
实验结果
单纯对没有进行抢票的用户提交单次抢票的请求进行测试，并发支持大约为80-85请求/s
测试环境(服务器):
----------------------------------------------------------------------
CPU model : Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz
Number of cores : 1
CPU frequency : 2199.998 MHz
Total size of Disk : 25.1 GB (9.7 GB Used)
Total amount of Mem : 985 MB (622 MB Used)
Total amount of Swap : 1023 MB (354 MB Used)
System uptime : 24 days, 3 hour 38 min
Load average : 0.00, 0.01, 0.01
OS : Ubuntu 18.04.1 LTS
Arch : x86_64 (64 Bit)
Kernel : 4.15.0-34-generic
----------------------------------------------------------------------
I/O speed(1st run) : 538 MB/s
I/O speed(2nd run) : 531 MB/s
I/O speed(3rd run) : 517 MB/s
Average I/O speed : 528.7 MB/s
----------------------------------------------------------------------
Node Name IPv4 address Download Speed
CacheFly 205.234.175.175 177MB/s
Linode, Tokyo, JP 106.187.96.148 19.0MB/s
Linode, Singapore, SG 139.162.23.4 6.99MB/s
Linode, London, UK 176.58.107.39 13.3MB/s
Linode, Frankfurt, DE 139.162.130.8 15.0MB/s
Linode, Fremont, CA 50.116.14.9 29.8MB/s
Softlayer, Dallas, TX 173.192.68.18 44.6MB/s
Softlayer, Seattle, WA 67.228.112.250 73.1MB/s
Softlayer, Frankfurt, DE 159.122.69.4 6.49MB/s
Softlayer, Singapore, SG 119.81.28.170 11.3MB/s
Softlayer, HongKong, CN 119.81.130.170 11.7MB/s
----------------------------------------------------------------------
Node Name IPv6 address Download Speed
Linode, Atlanta, GA 2600:3c02::4b 35.6MB/s
Linode, Dallas, TX 2600:3c00::4b 44.4MB/s
Linode, Newark, NJ 2600:3c03::4b 29.5MB/s
Linode, Singapore, SG 2400:8901::4b 12.5MB/s
Linode, Tokyo, JP 2400:8900::4b 20.6MB/s
Softlayer, San Jose, CA 2607:f0d0:2601:2a::4 81.7MB/s
Softlayer, Washington, WA 2607:f0d0:3001:78::2 22.4MB/s
Softlayer, Paris, FR 2a03:8180:1301:8::4 12.5MB/s
Softlayer, Singapore, SG 2401:c900:1101:8::2 11.0MB/s
Softlayer, Tokyo, JP 2401:c900:1001:16::4 8.61MB/s
----------------------------------------------------------------------
服务器带宽:1Gbps
mysql:mysql Ver 14.14 Distrib 5.7.23, for Linux (x86_64) using EditLine wrapper
python:Python 3.6.6
django:1.9.5
测试结果:
以300线程同时并发，三万个用户在一段时间内抢三万张票为用例
未修改数据库结构
平均响应时间:4600-4800ms (min:320ms,max:87050ms)
错误率(返回502/504): 1.57%
每秒处理的请求数:67.2 (开始时大约75-77，随着压力测试逐渐进行下降到约65， 最低时达到55)
修改数据库结构后(删除unique_id的索引,删除外键)
平均响应时间:2800ms (min:330ms,max:67528ms)
错误率:0.34%
每秒处理的请求数:94.7 (开始时大约100-102，随着压力测试逐渐进行下降到约95， 最低时达到90)