初涉性能测试

前段时间被要求做某个业务模块的压力测试，虽然之前培训过，还是一脸懵逼，而且公司内部也没有可以询问的同事，鉴于这种情况，就各种百度，总结出一个比较简单的流程。

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：以上每个参数值设置根据系统调节，不一定是写死的。