性能测试---问题记录

1、跑稳定性之前要检查环境：

• 压力机磁盘空间（因为跑稳定性过程中生成的result文件的数据不断增加，如果压力机磁盘空间不够就会导致压力停止）。
• 清空服务器日志，日志改成error模式，检查服务器空间大小。
• 数据库表空间是否足够。
• 清空gc日志（方便观察稳定性的 gc情况）。
• 如果执行过程中会生成数据并且数据保存在磁盘上，则需要考虑写个定时任务定时删除数据（如果这些数据可删除的情况下）。

2、脚本报错

• 压力执行过程中刚开始没报错，后来持续报错
  • 检查日志是否满了或者表空间满了。
  • 是否是数据太多，返回结果太多造成的。

3、稳定性过程中有支交易的响应时间越跑越高：

• 检查该交易的最高响应时间是否超时，如果超时则要优化，如果不超时，可否优化？
• 单跑该交易，观察响应时间是否越跑越高。
• 检查该交易是要处理数据还是查询数据，依赖哪些表，是不是依赖的表的数据增加才导致该交易响应时间增加的。
• 重测场景，去掉会增加数据的交易，看该交易响应时间是否增加。
• 如果能优化最好，如果不能优化，应该在测试报告中说明。
• 通过分析得出该交易响应时间的增长是因为其他表的数据增长造成的，生产上每天凌晨都会清理一定的数据，所以该交易的响应时间增长不会造成生产超时的存在。

4、负载测试超时

• 从最简单的地方开始分析：检查压力机、应用服务器、数据库服务器是否存在硬件瓶颈，是否存在网络瓶颈。
• 检查该交易对应的表的数据是否过多，超时大部分是数据库原因造成的。
• 重压超时的交易，查看哪些表没有索引、全表扫描等。如果有索引，查看是否有的数据没走索引。
• 如果走索引，检查该交易是否查询的字段太多（比如业务要求一次性处理365条数据，操作比较大）。
• 参数化数据太少了，数据库有行锁导致响应时间超时，加上足够的参数化数据即可。
• 参数化数据太少了，引起对数据库表的挣用，造成死锁，所以报超时错误，加上足够的参数化数据即可。
• 数据库表锁、行锁、锁等待、死锁都会造成超时（Oracle的用对应的sql查询是否有这些问题存在）。

5、线程池占满

• 监控tomcat中间件是为了监控线程池的使用情况，如果tomcat里还配置了数据库连接池，也要监控数据库连接池的使用情况。假如配置了300个线程池，那么如果监控到这300个线程池都属于繁忙状态，那说明线程池不够用了，后面的请求都属于排队状态，排队需要等待，会导致响应时间增长。但如果配置的线程池太大，则会浪费资源。所以需要减少不必要的线程池的浪费。
• 通过通过manager status监控tomcat，修改tomcat/conf里的tomcat-users.xml进行配置，配置角色、用户名、密码，重启tomcat。
• 访问http://localhost:8080/manager/status进行监控。
• acceptCount="300"，指的是当线程数达到maxThreads后，后续请求会被放入一个等待队列，这个acceptCount是这个队列的大小，如果这个队列也满了就直接refuse connection。
  • 场景1：接受一个请求，此时tomcat启动的线程数还没有达到maxThreads，tomcat会启动一个线程来处理该请求；
  • 场景2：接受一个请求，此时tomcat启动的线程数已经达到了maxThreads，tomcat把该请求放入队列，等待空闲了再来处理；
  • 场景3：接受一个请求，此时tomcat启动的线程数已经达到了maxThreads，且acceptCount也达到了最大，此时tomcat会拒绝此次请求，返回refuse connection错误。
• 调整tomcat最大连接数，可以增加maxThreads和acceptCount，并且使acceptCount大于等于maxThreads。
• maxTreads的值应该根据流量的大小，如果值过低，将没有足够的线程来处理所有的请求，请求将进入等待状态，只有当一个处理线程释放后才被处理；如果设置的太大，tomcat的启动将花费更多的时间。所以该值需要实际测试分析得出，可通过前面讲的managerstatus监控页面得到。切记不能一味的扩大该值，瓶颈无法突破时，可以使用tomcat集群来提升性能。