性能瓶颈分析(一)

133 阅读2分钟

持续创作,加速成长!这是我参与「掘金日新计划 · 10 月更文挑战」的第9天,点击查看活动详情

  1. 分析性能测试的五大图表(聚合报告、线程数、响应时间、TPS、吞吐率图)

a) 分析时有个很核心的理念就是有标准走标准,没有标准看趋势

  1. 通过实时监控工具(nmon 等)监控分析

a) 系统在运行过程中 CPU 是否稳定运行或 CPU 耗用是否过高

b) 在系统运行过程中其内存是否存在内存泄漏现象

c) 打开应用相应日志,分析在运行过程中是否存在交易报错并获取错误原因查看是否由于代码原

因导致交易发生错误。

聚合报告:

image.png

Label:请求名称

样本:请求的次数,从这里可以样本数是梯度减少的,因为在最后时间结束的时候请求被中断,所以导致的结果。

平均值:是每个请求的平均响应时间,单位是毫秒。一般有 1-3-5 法则(均在 1-3 秒以内) 说明结果还算过得去。

90%百分比:是用户体验数据,指 90%的用户会在这个值以内,在这里的 90%值低于 10 秒 表示还过得去。

异常%:我们能够容忍错误在某个范围以内就行了,不要求 100%正确。但是一般会期望在 1%以内,在这里差不多达到了 10%则需要分析是什么原因导致了过高。可以对异常过高的 请求加入查看结果树进行分析,分析如果是业务原因则需要优化,如果不是业务原因则应该 剔除这些出错再进行计算。

Active Threads Over Time:活跃线程数/时间

image.png

一般是用来辅助其他图表的分析,在这里一直都是 20 个用户,包括服务器也没有变化, 用户数也没有变化,那么其他图表的数据表现也应该没有变化。

Response Time Over Time:响应时间

image.png

最后半分钟,数据是异常的,这是没有意义的,数据一般只看中间。因为大量的折线导 致看不清,可以过滤掉部分折线。看规律也是在不同的时间段应该保持同样的规律,平均响 应时间还是在 2-5-10 规则中。另外需要说明的是,平均响应时间存在长时间的过大和长时间的过小都是有问题的。