需求性能指标
明确性能需求是一个关键点,我们要明确在什么样的业务压力场景下要求这样的指标。
平均值
标准方差---毛刺
没有业务指标就没有技术指标,我们的工作就是让
业务指标(比如并发用户数、在线用户数等) 和
技术指标(比如 CPU、IO 等)对应起来。
在不同的性能场景中要定义好不同的性能需求指标,有些是自己看的,有些是给别人看的。
性能场景
性能场景:
基准场景
容量场景:
最重要的是业务比例,即我们常说的业务模型
响应时间
稳定场景
稳定性的时间长度要合理,也就是说要合理判断稳定性场景需要运行多长时间;
稳定性使用的 TPS 量级要合理,也就是说我们要合理判断稳定性场景应该用多大的压力执行。
异常场景:
针对系统的架构,先分析异常场景中的需求点,再设计相应的案例来覆盖。
为什么要分析系统架构呢?因为在一个应用中,我们把功能测试完一遍之后,异常问题通常有两大类:
其一是架构级的异常;
其二是容量引起的性能异常。
对于架构级的异常,我们只能站在架构的角度进行分析。
性能场景:场景绝对不止脚本和业务模型
场景分为四类(基准、容量、稳定性、异常);
执行过程中要保持连续递增。
【“场景”的重要性】场景是性能方案的落地,也是性能实施的核心,更是性能分析的起点
性能场景:
性能脚本
接口级脚本
业务级脚本
用户级脚本
参数化数据
监控策略:不要过度监控,先全局监控,有问题再定向监控
全局监控
定向监控
执行控制:按照基准-容量-稳定性-异常顺序执行
场景执行顺序
实时数据分析:实时查看监控曲线决定是否继续
场景调整:
压力线程
递增策略
递减策略
持续时间
软硬件环境
基础数据/铺底数据
挡板/Mock/第三方
性能分析:
性能分析决策树;
性能瓶颈证据链。
RESAR性能分析七步法:
第一步:压力场景数据。
压力工具提供的数据只有两个曲线最为重要:
一个是 TPS
一个是 响应时间。
第二步:分析架构图。
分析架构图,看压力流量的路径。
主要是为了看分析链路的前后关系。如果业务逻辑复杂,部署也复杂,那我们就可以分为业务路径和部署路径。如果不复杂,那画一个路径就够了。
第三步:拆分响应时间。
在性能分析过程中,拆分响应时间是分析的关键起点。
第四步:全局监控分析。
全局监控能力的工具平台
根据性能分析决策树,来补全性能计数器。
“全局监控分析”要求你对所看到的计数器有足够的了解。如果你看了数据之后,没有任何反应,那就说明你还没有达到分析的能力。
比如 GC 的频率,只要 GC 不影响系统容量,那就是可以的。
第五步:定向监控分析。
通过全局监控计数器之,知道哪个方向上有问题后,才去做定向的监控。
在 RESAR 性能工程中一定要强调——证据链。
第六步:判断性能瓶颈点。
有了证据链,就一定要来到性能瓶颈点的判断过程。
比如说,我们在栈中判断有没有锁的存在,那至少你要在栈中找到这个锁有哪些线程在等待,哪个线程持有。
再比如说,我们要判断一个 SQL 慢,那至少你要把 SQL 的执行过程拿出来,看到底是哪一步有问题。
第七步:确定解决方案。
给出解决方案是我们性能人员的重点。
应用RESAR性能分析七步法,请记住:在性能分析中,你只需要知道下一步做什么就可以了,我们终会找到瓶颈的具体原因。