搭建私有PTS性能测试服务(六)

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服务的介绍就全部介绍完了,后续就看大家怎么使用该工具在项目中发挥了,谢谢大家的关注和阅读。


全篇完

发表评论

电子邮件地址不会被公开。 必填项已用*标注