nGrinder测试结果分析前几篇我们介绍了怎么对nGrinder改造成阿里云PTS类似的样子,也给大家举例演示了怎么利用nGrinder测试接口性能,那测试结果出来后,就需要对测试结果进行分析,找出性能瓶颈点,今天给大家介绍怎么分析nGrinder的测试结果。
结果图表介绍
测试概要
测试结束后,会列出测试概要信息,如上图,包括:
- 虚拟用户总数
- 平均TPS
- TPS峰值
- 平均响应时间
- 执行测试数量
- 测试成功数量
- 错误数
- 运行时间
右侧是TPS图,下方还有agent的运行日志,可以下载共测试分析。
详细测试结果
详细测试结果页面,除了列出了概要页面的信息外,还包括:
- 开始时间
- 结束时间
- 测试时间
- 运行时间
- 描述
- 运行的代理数量
- 进程/线程数
- 忽略采样的数量
- 详细的测试结果图表
TPS图,每秒事务数,反映了某一时刻,同时运行的事务数,这里的事务即为注册的操作过程。
平均响应时间图
首次接收数据的平均时间,此图反映了从客户端发送请求到服务器返回第一个数据包的时间,一般在内网测试可以忽略网络的问题,如果此时间很长,说明服务器响应很慢。如果服务器的负载不高,而出现了很多响应超时的情况,此时间也很长,说明网络可能有问题。
虚拟用户运行图,从图可以看出虚拟用户的加载变化
错误数图,翻译了某一时刻的出错数
CPU使用率图,目标服务器的CPU使用率。
内存使用情况图,目标服务器的内存使用变化情况。
每秒接收的字节数,反映了入网的吞吐量。
每秒发送的字节数,反映了出网的吞吐量。
自定义监控图表1,用户自定义搜集的数据变化情况。
简单分析举例
接着注册接口的测试举例,我们在测试时,不光要看服务器的资源变化情况,应用程序的运行日志也是我们需要关注的点。 第一次运行50个并发
平均响应时间超过了10秒,很恐怖了,TPS均值还不到4。web服务器的CPU波动很大。
再看mysql服务器的CPU使用率
均值超过了60\%,说明mysql服务器压力稍大,再进一步分析mysql的慢日志
发现报了很多慢查询,注册需要查询user表,查看索引配置,发现只给email加了索引。给name字段也加上索引后再次运行测试。
性能提升明显,平均响应时间降到了3秒左右,TPS均值提升到了14。web服务器的CPU此时已经满负载
mysql服务器的CPU均值在20\%左右
通过此次测试,我们至少发现了注册接口的一个性能瓶颈点——user表没有给name字段加索引。 至此,在内网搭建PTS服务的介绍就全部介绍完了,后续就看大家怎么使用该工具在项目中发挥了,谢谢大家的关注和阅读。
全篇完