本文分享了一次真实的性能测试案例，描述了在银行项目中遇到的TPS下降和响应时间上升的问题。经过排查，定时任务、测试代码、业务代码和FGC都不是问题源头。最终发现是负载均衡工具haproxy导致的问题，去掉haproxy并使用自定义分配方式后问题解决。提醒大家在性能测试时要注意负载均衡工具可能带来的影响。
临近双11又开始另一轮的性能测试，陆续给大家奉上性能测试系列篇，从性能测试理论、性能测试案例高延迟（响应时间长）、CPU问题、内存问题、线上问题实战和性能测试书籍推荐等篇章。更多性能文章见文末链接。
陆续聊了性能测试指标和性能测试排查过程也有四五篇文章了，今天分享一个真实的性能测试真案例。
在一次某银行项目性能测试中，当系统运行到1个小时10分左右：tps出现明显下降,响应时间明显上升，其他相关业务cpu、内存、网络等各项指标都正常；此问题一直重复出现，而且在银行测试环境和公司测试环境一直存在。
通过分析怀疑可能是以下原因造成的
1.定时任务，
2.测试代码，
3.业务代码，
4.FGC。
然后就根据猜想一项一项测试验证。
停掉所有定时任务，和开发确认没有段时间插入定时日志或者其他数据库操作。
检查测试代码，测试代码和正确的测试代码只有很少的几行差异，而且全部是http连接规范的写法，不至于有问题。
业务代码，检查所有业务日志，tomcat日志，jstack抓trace等，都未见异常。
Full GC 通过抓jstat信息，发现在50分左右确实出现fgc如图：
但在相同时间，该接口的TPS有少量下降， 不是原来遇到的大量下降，如图
故排除fgc问题。貌似再次测试进入死胡同，再次怀疑此应用代码问题。
就在早上突然想到是不是负载均衡工具有问题？？？？到公司迫不及待的测试下。
通过测试，去掉负载haproxy代理，自己写了一个随机分配到四个应用节点地址，通过三个小时测试，没有出现上述怪异的问题。
告诫各位，在性能测试时，特别要小心软负载工具的应用，对性能测试的影响， haproxy工具坑我好几次了，使用时一定要小心。
文章来源：MiniStarClub北京，致力于提供最具价值的测试及测试管理领域原创文章。包括测试技术、测试方法、测试思想、测试管理等。
· 推 荐 阅 读 ·
RECOMMENDATION
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
