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

全篇完