TPS从300笔/秒到5500笔/秒的性能测试优化之路

Posted 2020-10-17

? ? ?TPS从300笔/秒到5500笔/秒的性能测试优化之路

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?郭柏雅

本文案例是我们品课学院在银行系统性能测试第一个案例，由发生至解决，通过对业务逻辑的认知、测试环境的了解、测试脚本的开发、服务的监控分析优化、操作系统的监控分析与优化、从基础软件到架构级优化改良、测试报告的编写等，一路艰辛，但是最终柳暗花明。

?问题总结回顾

1.??? 每一次攻坚性能故障问题都是一次精喜的探险，需要清醒头脑、大局观的分析意识、扎实的专业基础等更要凝结你的意志和自信心，因为这是一个艰苦而有趣的过程。

2.??? 纸上得来终觉浅， 绝知此事要躬行，一切性能测试与问题的分析优化，不是看完一篇文章做完几个项目就能提升，需要持续兴趣吃苦的煎熬来不断提炼优化自己的知识与技能才能慢慢的在博大精深的性能世界里认知了解游趟。

故事案例发生原因

故事原因：某知名城商行代支付管理系统，因上线一段时间后客户量剧增，在生产运行过程中偶尔会出现资源争用现象，客户领导担心目前环境无法满足业务量日益增长发展趋势。 因此该行邀请一家合作公司帮忙测试分析问题，该供应商跟他们合作关系一直友好也很支持，派了一位十几年性能测试经验的行业专家过去，因业务逻辑、技术框、测试脚本等编写比较复杂，工作量也大支持了十几天后，因该性能测试专家临时有事情，只能忍痛隐退，这时该供应商刚好项目紧张人员无法抽取，找到我们品课学院，让我们帮忙测试，得此机会我和柠檬老师两个利用周五晚上和周末时间过去支持，柠檬老师主要负责压力测试和测试数据维护工作，我负责性能定位分析优化和测试报告编写，因时间紧迫，测试过程中没有使用第三方工具，都是直接使用命令或者数据库自带的函数等进行监控分析。

?测试实施场景

?到客户现场后，客户开发人员很耐心的帮我讲解了业务逻辑、技术框架等以及环境情况，也介绍了目前情况，在高并发下TPS 大概在300笔/S，而且上下波动很大，目前尚未查出具体问题原因，希望能在最短时间内帮忙定位出来，不然已经临近上线，还好长期在金融行业做性能测试，能短时间内理清问题的来龙去脉，也最快的时间内切入到团队中。因每个人写脚本、参数化方式风格不一样，我也看了之前脚本编写很规范，但是每个人对脚本的使用方式有点差异性，我花了点时间重新修改编写LR脚本、shell脚本，估计是运气好或者有相关项目经验，在压力测试过程中，就发现问题并提供解决方案，通过描述问题原理以及操作系统工作原理、交易脚本使用原理等跟客户开发人员交流后，就这样客户也在最短时间内从陌生到认可，并得到大力支持，运气来了，做事就是给力。

这次接口实时交易测试数据准备相对比较简单，不用准备存量的业务数据，只需把对应的业务脚本T0交易的脚本参数化好，确保高并发下不出现业务数据重复即可，而针对T0插入到过程表的数据，通过使用verify交易进行时时查询处理到目标表，具体脚本如下：

1、? 实时交易都是接口报文，分为socket协议脚本T0交易和http协议脚本verify交易，其中HTTP协议脚本是对T0的socket脚本插入到过程表数据进行查询后更新然后插入到目标表。

2、? 批量脚本，需要每秒钟传输一个文本文件1.5M的txt文件到应用服务器指定目录下，让后台去处理。

?

Socket协议脚本相对比较简单，类似如下：

? ? ? ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

测试过程问题分析

优化前：TPS只有304笔/秒，而且不稳定，在并发到一定时间后，TPS就掉下去，而且交易成功率80%不到，随时间推移交易成功率也会持续降低，没办法满足预期指标要求550笔/S，交易成功率99%，优化前测试结果如下图：

? ? ? ?

1、数据库问题分析优化方法

在压力测试过程中发现TPS不高，而且随着用户并发数增加TPS反而降低，交易成功率也逐渐下降，看了各服务器资源使用都在理想状态下，与实现怀疑下数据库是否有问题，因测试交易是接口测试，语法相对简单，都是单表操作，查看了数据库相应的parameter数值，发现都是默认配置，无法满足高并发，于是建议他们DBA修改下SGA、连接数等数据库参数，，重新并发发现TPS有明显提升，但是还是没办法满足指标要求，因为磁盘IO高了，于是抓取语法分析，都是类似如下锁：Select ….for update,说明问题是Lock For Update,Lock Row Share?，在并发时打开一个游标，以及返回集中的数据行都将处于行级(Row-X)独占式锁定，其他对象只能查询这些数据行，不能进行update、delete或select for update操作。

3级锁有：Insert, Update, Delete, Lock Row Exclusive
说明在没有commit之前插入同样的一条记录会没有反应, 因为等待上一个锁释放掉才能继续工作。语法是没办法修改，所以把单笔commit，改为多笔同时commit，解决高并发问题。

?

1.1? 表面性能问题监控

监控数据库磁盘IO写入一直偏高，如下图：

oracle函数看到后台数据库块写数据问题情况，如下，

1.2 内核问题定位分析

通过与开发人员分析，因为T0交易在高并发写入到过程表，这时HTTP接×××易会去查询出对应的过程表数据，然后for update，最后在更新插入到目标表。当过程表数据量很大情况下，会出现锁现象，如下图，看到过程表数据时时动态增加变化：

而在过程表数据量逐渐增加情况下，前端TPS 也在降低，失败率也在增加，如下图：

?

? ? ? 2、应用方面问题分析优化

而应用方面，在通过java批处理方式调度实时处理过程表数据后，对于一些业务规则判断代码也做了优化，后面我们在java应用中监控到java内存回收使用有点异常，发现JVM参数配置不合理，内存回收不及时问题，通过优化配置JVM后，以及把对应应用日志记录级别做了修改后，TPS可以稳定在800笔/S，以上。

3、其他问题分析优化方法? ??

经分析后，在To对应的SOCKET交易与过程表verify对应的HTTP交易脚本并发数配比改为2：1，然后开发人员后台调度时时java批处理及时处理掉T0交易的数据，确保过程表数据量都在100笔以下，

这时的TPS，稳定在660笔/S，交易成功率也在99.9%，不会大批量出错现象。

??

性能优化攻坚战后期：

测试环境硬件配置：应用服务器三台，数据库一台，负载均衡服务器一台，在高并发下，三台服务器处理很轻松，但是在更高用户并发下，TPS还是上不去，资源利用率也不行，反而失败率会增加，客户领导希望能继续挖掘问题，因此只能在继续发挥想象力，从全局角度看待问题，碰巧发现操作系统的文件句柄数量不足，于是让客户帮忙修改了下，发现TPS有适当提升，可以达到800笔/S，但是还是不能满足现状，发现压力测试时间久了，TPS就会抖动，而且越往后越厉害，说明资源释放有点问题，需要时间释放，然后才能回收，TPS才能提升，发现HTTP交易verify在处理过程表数据的时候，端口申请数量一直增加不能马上释放，以为是操作系统参数设置问题，于是就修改了操作系统参数，tcp_syncookies 等参数，但是在高并发下还是有问题，后来经推敲分析是verify脚本处理过程表数据给下游时是走HTTP协议，高并发下需要申请不同端口等，只能架构调整分离，然后在负载分发方式处理，TPS终于从800笔/S，直接飙到大于5000笔/S，而且成功率达到99.99%，资源利用率也上去了，终于大功告成。

我们的攻坚团队

在测试过程中，客户领导、两位开发人员、我和柠檬一起加班熬夜分析攻坚各种技术问题，才能短时间内顺利的把任务完成。

性能问题定位分析是一种技术活，性能优化分析是一种艺术活，达芬奇的艺术来源以长期技术的锻炼积累得来灵感，而性能测试分析优化也是如此。对于一个大项目的性能测试分析优化，不是一个人能完成的事情，是需要一个团队协作，是需要一个拥有高度的执行力的团队，是一个责任分明的团队，在应对突发、严重、紧急情况时，能通过专门的攻坚团队来解决这类问题，这个团队应该包括项目组的核心专业人员，有较强的动手能力和研究能力，能够变通解决问题，思路开阔。他们的作用是至关重要的，往往可能决定项目的成败。