单接口性能测试与分析
使用的jmeter进行性能测试
先在本地编写测试脚本，没问题以后在服务器中运行
1.进入服务器jmeter的bin目录下，非GUI模式下压测：
2.运行：jmeter -n -t jmx脚本在服务器的存放路径 -l jtl文件生成路径
3.运行过程中可查看应用服务的日志，看是否报OOM等异常错误
4.注意：在运行脚本之前，需确定应用服务器与数据库服务器中资源在上次脚本运行结束后已释放。（应用服务器与数据库服务器监控可与公司运维查看）
- 查看应用服务的CPU使用率与平均负载是否降至最低，
- 查看TCP连接数是否释放，
- 查看内存使用率是否降至最低
5.运行结束后，需将运行时间段内的应用服务器与数据库服务器的资源暂用情况进行收集（截图），主要收集内容：
- 不同的场景
- 每个场景下收集的内
- 进行数据收集
性能测试报告
1.测试目的
评估XXXapp服务端常用接口当前最大性能并查找性能瓶颈。
2.环境
测试环境（服务、云环境、ip地址、系统配置）
生产环境（服务、云环境、ip地址、系统配置）----负载均衡
数据库最大连接数、JVM参数设置
说明：
- 服务器配置与生产环境一致
- 数据库链接数和JVM参数均与生产环境一致
- 测试环境模拟单节点进行测试，测试结果均为单节点4C16G配置性
3.被测接口
| 功能名称 | 请求方法 | 接口地址 | 参数化 |
| 接口A | get | ||
| 接口B | get | 有，goodsId | |
| 接口C | get |
4.测试结果
接口A
测试场景及结果
| 场景 | 并发线程 | 运行时间 | samples | ART(ms) | 90%(ms) | QPS | ERROR |
| 场景一 | 5 | 600 | 588918 | ||||
| 场景二 | 10 | 600 | 954976 | ||||
| 场景三 | 15 | 600 |
测试分析
- 对比场景一与场景二，场景二QPS为，90%响应时间为Xms，系统资源均在正常范围以内，如下图所示
场景一应用服务器cpu使用情况
+CPU使用率图
+CPU平均负载图
场景二应用服务器cpu使用情况
+CPU使用率图
- 观察场景X运行期间，系统资源使用情况，应用服务器CPU利用率已经达到88%，CPU负载极不稳定，已经有超过10的情况，结合服务器配置为4C，说明应用服务器CPU已经出现瓶颈。其它资源使用正常
+应用服务器CPU利用率图
+应用服务器CPU平均负载图
+数据库服务器CPU、TPS、qps图
- 观察场景X，X并发线程数，应用服务器cpu平均负载仍然达到10以上，且随着场景运行有上升的趋势，同时数据库存在4次慢查询
- 观察系统资源使用情况，场景X，20并发线程数，应用服务器cpu平均负载已经达到X，说明CPU已经出现排队现象
- 脚本执行过程中，后端日志异常出现内存溢出情况，导致错误率达到43.40%
- CPU负载接近10左右，内存使用率逐渐上升，如果场景持续运行，内存使用率将会爆满
综上所述，文章详情接口，单节点最大QPS为XXX，90%响应时间为XXX
综上所述，领券接口性能较差，有OOM异常，请开发排查定位！
结果汇总
| 接口 | 最大并发进程数 | 运行时间（s） | Samples | 90%ART(ms) | QPS | CPU | CPULOAD | MEM |
| 接口A | 10 | 600 | 862432 | 10 | 1437.6/s | 70% | 7.9 | 59.88% |
正式环境接口请求数据信息
| 日期 | 接口总访问量 | 接口 | 访问次数 | |
| 2020/07/03 | 6817 | 接口A | /api/.. | 568 |
每天接口访问次数基本都在1000以下，生产环境压力较小。相比较测试结果来看，当前接口均满足生产环境性能需求。
