性能测试项目中遇到的问题和解决方法

做性能测试过程中遇到了一些问题，现总结下来，希望能给大家带来一些参考，写的不好请多包涵和指教。因为是公司的项目，为避免信息泄漏，所以把相关信息涂掉了。

问题一：

做接口性能测试时，单用户时响应时间是50ms左右，而测10个用户并发时响应时间达到了260ms，虽然没有超出指标，但正常情况下单用户和10个用户并发时响应时间不应该相差那么大。

排查步骤：

1、查看是否有资源瓶颈

重新压测该接口，观察应用服务器、数据库服务器、压力机资源使用情况，发现使用率并不高，所以可以排除压力过大造成的资源瓶颈。

2、查看TPC是否能正常连接和释放

用netstat -nat|grep -i "端口"|grepTIME_WAIT|wc -l命令查看TIME_WAIT情况，如果TIME_WAIT的值很大并且一直增加的话，说明tcp不能正常释放，会造成响应时间增加。

可以看到TIME_WAIT的值并没有很大，也没有一直增加，可以排除tcp连接问题。

3、查看磁盘使用情况

因为测试环境调试时是info级别，发压力的时候会产生大量日志，占空间特别大，每清理一次过不了多久又快满了。

4、为避免稳定性测试的时候遇到磁盘满了导致场景停止的情况，写一个定时任务定时清理日志。

问题二：

利用晚上时间跑个12小时稳定性，第二天发现TPS曲线图成了这个样子。

排查步骤：

1、观察TPS图发现，几乎每两个小时TPS掉一次坑，是周期性的，而且TPS有掉到0的现象。LR上也有失败的交易，猜想是TPS掉坑的时候交易才报错，因为之前测负载的时候并没有交易报错。

2、查看服务器日志，发现报连接池不够错误。加大连接池晚上再跑一次稳定性。

3、重跑稳定性后没有周期性掉坑的现象了。分析掉坑原因是因为连接池太小，达到一定请求后，weblogic连接池断开连接，所以TPS降到0，自动创建连接后可以正常请求了，达到一定请求后又断开连接，才有周期性掉坑的现象。

问题三：

跑稳定性时发现，有两个接口的响应时间随着场景执行时间上升。

分析步骤：

1、刚开始测试时，测试环境数据库里的数据跟生产上的是一致的，生产上的清理策略是每天晚上12点清理一次数据，以确保数据量过大造成响应时间过长的情况。场景里有两个接口在测试时插入大量数据，跑一个晚上就能插入几百万条数据。而另外两个接口是分别查询这两个接口对应的表里的数据，数据越多，返回的结果越大，所以响应时间呈上升趋势。

2、查看awr报告，发现条件只有一个multi_tenancy_id，单从数据库来看没啥优化方法。

3、从数据库着手，写个数据库定时任务清理数据。因为生产环境会一天清理一次数据，所以生产环境上的数据没有那么多，也不会如此大的压力。测试时要压到资源瓶颈，是为了测出最大处理能力，稳定性是按照最大处理能力去跑的，此时能达到850TPS左右，考虑到生成的数据量太大会引起其他接口执行过慢，所以我们定时清理数据库，设置一个每小时删除一次数据库表数据的策略。

不中

4、重测稳定性，那两个接口没有再出现响应时间越来越长的问题。

问题四：

我们知道测试稳定性的目的是为了观察有没有内存溢出情况。跑了12小时之后，用HPJmeter打开gc文件，发现还没有达到能触发fullgc的回收点。

nmon监控结果：

分析步骤：

1、从nmon的监控结果也可以看出，前期内存缓慢增长，上升到一定程度曲线平了，但是不能确定平了的那块是什么情况

2、此次稳定性测试压力过小，或者运行时间不够长，没能正常触发fullgc回收，不能确定是否能正常回收。

3、重测该场景，考虑到测试时间有限，最优处理能力跑24小时不能正常触发fullgc回收，就用极限压力去测，反正目的是观察内存回收情况，如果能正常回收了则能证明不存在内存溢出情况。