初涉性能测试
前段时间被要求做某个业务模块的压力测试,虽然之前培训过,还是一脸懵逼,而且公司内部也没有可以询问的同事,鉴于这种情况,就各种百度,总结出一个比较简单的流程。
1、需求:
各位领导讨论多次订了一个,但是在最后实施的时候发现没有足够的测试经费支撑,最后又经过多次商量(中间差点就放弃测试了)之后决定做个有挡板的单机压测。
这个业务模块首次上线,根据以往系统总的客户数量和未来2个月可能产生的客户高峰,
最终 TPS:14/sec。
2、测试环境准备:
让开发和运维帮忙搭建了一个和生产环境相同配置(CPU、内存,硬盘,网络,tomcat)的测试环境。
3、测试工具:
用loadrunner和jmeter同时试验了一下,发现loadrunner太重,在我的虚拟机很容易死掉。最后选择jmeter。
4、测试脚本:
(1)由于我们的系统是基于HTTP协议的,所以脚本相对简单些,熟悉jmeter常用组件就可以了,如:HTTP请求、响应断言、查看结果树、聚合报告等。
5、测试数据:
业务相对单一,数据库也是导的生产库数据,测试数据准备了10W+(最后实际测试下来发现足够了)
6、测试中遇到的问题:
(1)集合点的设置和开发同事意见不统一,经过多次测试参考百度搜索到的一个公式:超时时间 > 请求集合数量 * 1000 / (线程数 / 线程加载时间)
(2)因为是一个业务模块的挡板测试,比较纠结测试结果是以聚合报告 总体中的TPS还是单个接口的TPS来判断。最终按照整个流程跑完单接口的TPS是多少来判断,又因为加了挡板,保守估计大于30TPS比较合适。
(3)经过多次测试,发现我们的业务单机压测设置线程数50-100,集合点设置30-50比较合理。
7、系统分析和优化 :
(1)刚开始整个业务流程下来,TPS在2~3。。。以为自己的测试方法有问题。
(2)监控是用JDK自带工具jvisualvm 和Linux下的top还有free。jvisualvm 可以监控到耗时最高的方法,然后扔给开发GG(JAVA代码的技能得快速补起来)做优化。首轮优化之后TPS达到13+。还是不满足需求。
(3)单个接口测试,找出TPS最低的接口,再用jvisualvm 工具找到耗时最高的方法,让开发GG人肉代码。发现是因为某个循环导致,优化代码最终满足基本需求TPS达到33+
(4)测试期间也优化了tomcat连接配置,开放到最大连接数。
(5)系统优化后,做了一个稳定测试,发现error率<1%可以坚持2H(优化控件很大啊)
8、总结:
(1)7个接口测试和开发优化时间差不多两周完成。
(2)经过时间验证也hold住了这个小高峰。
(3)遗留问题:CPU很高达90%,时间太紧张,问题遗留后续处理。
PS:以上每个参数值设置根据系统调节,不一定是写死的。