性能场景执行完成后,便是测试报告阶段。
测试报告阶段
测试报告是统计场景执行并得出结论的阶段,结论包括生产配置参数与性能报告两部分。
生产配置参数
生产参数配置可能大部分由有经验的运维给出,但作为性能测试人员,给出生产配置参数也是合理的。
那么如何给出生产配置参数呢,这里针对微服务架构分:
- 情况一:生产架构是多服务单节点,包括还没有上生产环境的,这种情况一般属于初创企业
- 情况二:生产架构是多服务多节点,呈集群部署,这种情况属于大部分一般企业
我属于情况一,生产架构是单服务节点,且部署在一台单机上,所以这一块直接复制测试环境的配置即可(前提是测试环境的TPS满足预期的容量规划,如果不够需要进行等比扩容,做线性评估测试)
对于情况二,高楼老师给出的解决方案分为以下五步:
第一步:预判生产流量
大概得出生产流量的量级(峰值情况),不用特别精准。
第二步:确定系统组件
之前阶段已经理清系统用到的各种组件,然后分别对各个组件得出性能配置,其中性能配置又分为硬件配置和软件配置
第三步:硬件配置对比
分别统计生产环境与测试环境的硬件环境,以及峰值条件下的资源利用率、TPS、RT数据,比画出表格对比,如下图
为什么要统计生产的TPS等情况呢?容量规划,直接用测试环境做等比评估不就行了吗,我当时看到这里想了很久,以下是我自己的见解。
首先容量测试解决的问题无非两种情况:
一是找到当前硬件条件下系统的最大TPS;二是为支持系统未来某种场景下的TPS提供依据。
按照上面表格来算,理论上当测试环境的CPU资源利用率是30%的时候,对应的TPS应该是3000,所以下面增加一行测试环境实际跑出来的TPS。
- 当该TPS小于3000时,我们还需要继续调优
- 当该TPS大于等于3000时,我们需要继续增加2个场景:60%CPU资源利用率、90%CPU资源利用率
假如30%CPU的TPS为3000,60%CPU的TPS为6000,90%CPU的TPS为9000,则TPS与CPU利用率呈线性关系,可以得出生产环境当CPU90%时该硬件下系统最大TPS为90000。
但正常情况下CPU利用率越高,TPS会不稳定甚至越来越小,假如90%CPU的TPS为8000,则可以推断出生产环境当CPU80%时系统最大TPS为80000。
于是我们找到了当前硬件条件下系统的最大TPS,同理根据该表格等比模型,我们也能推断未来需要更高的TPS下的硬件配比。
注:其中资源利用率用性能决策树的全局计数器,因为每个业务系统消耗的资源会有偏向,要么是计算密集型(CPU),要么是 IO 密集型(内存/磁盘),所以,我们在比对计数器的时候,肯定要比对那些消耗得快的计数器。
第四步:软件配置对比
前面貌似仅用硬件配置就能得出系统的最大TPS了,是因为我们建立在软件配置最优的前提下(配置最优就是能产生最大TPS的配置)
那这里看软件配置是为了什么?
我理解是得到当前系统下最合适的配置参数,即适量减少TPS,来获得更快的响应时间。
在上面的表中可以增加软件配置参数列:
软件配置对比跟硬件有所差别,比如CPU,硬件关注的是型号、主频、核数,而软件层面就是CPU使用率,其他应用软件,高楼老师也罗列了比对参数
其中重要的java微服务应用,配置如下,可直接参考
第五步,获取测试环境配置值
依次调整配置参数,并执行场景得到对应的TPS,这时根据TPS可以确定最合适的配置参数了,高楼老师最后举例Java的应用服务的配置:
server: port: 8086 tomcat: accept-count: 10000 threads: max: 200 min-spare: 20 max-connections: 500
随后调整参数,找到合适的响应时间及对应的TPS,确定线程池(线程数)大小为50 、超时为200ms、队列长度为100。而具体的调大调小,取决于你是想让系统支撑更多的请求,还是想让用户有更好的体验了。
最后整理下等比模型表格,就得出了生产环境的软硬件配置参数。
性能报告
性能报告是一个性能项目的总结,是性能价值的最终体现。如果给老板做汇报,简明扼要即可。
性能报告结论
性能报告要给出明确的结论,表达的是业务系统的性能结论,比如:系统可支持 2000 万人同时在线,20000 人并发。
性能报告表现形式
一是尽量详细的技术型报告
这种报告通常是 Word、PDF、HTML 形式,报告内容包括项目背景、测试范围、需求指标、工具环境、数据量级、业务模型、场景执行策略、场景结果整理、场景结果分析、结论、问题汇总、后续性能工作建议、运维建议。
二是尽量简短型的汇报型报告
这种报告通常是 PPT、Keynote 形式,报告内容包括结论、基本信息描述(用几个简单的页面概括一下即可)、问题汇总、后续性能工作建议、运维建议。
性能报告的内容
主要包括执行场景前的信息与执行场景后的信息。
执行场景前的信息该要如下:
包括项目背景、测试范围、业务模型、性能指标、系统架构图、软硬件环境、压力工具及监控工具、数据、场景设计及报告策略、监控设计。
执行场景后的信息概要如下:
包括场景结果整理、场景结果分析、结论、问题汇总、后续性能工作建议、运维建议。
因为是自研的性能项目,我删减了部分内容,报告结构如下:
![](/i/l/?n=22&i=blog/992633/202210/992633-20221029102630802-63184008.png)
总之,重点内容要放在前面、详细的分析可附上链接、能用图的别用表、能用表的别用文字表述。
结语:在工作中虽然整体根据高楼老师的课程实践了一番,收获了很多,但实际效果没有展示出来,特别是获取生产配置参数这里,后续有机会再尝试,也欢迎大家补充讨论。
标签:实战,结论,场景,性能,配置,TPS,参数,CPU From: https://www.cnblogs.com/qgc1995/p/16582650.html