支付系统接口性能压力测试TPS优化之路

郭柏雅

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

 问题总结回顾

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

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

故事案例发生原因

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

 测试实施场景

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

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

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

2、  批量脚本，需要每秒钟通过使用FTP协议进行模拟从不同服务器定时触发传输文件大小为1.5M的txt文件，文件内容是类似二维表数据方式存储，传输到目标服务器后进行文件解析插入到对应服务目标库。

涉及性能测试业务脚本，通过loadrunner 的socker进行编写，如下

测试过程问题分析

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

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

在压力测试过程中发现TPS不高，而且随着用户并发数增加TPS反而降低，交易成功率也逐渐下降，看了各服务器资源使用都在理想状态下，与实现怀疑下数据库是否有问题，因测试交易是接口测试，SQL语法相对简单，都是单表操作，查看了数据库相应的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之前插入同样的一条记录会锁等待现象, 于是建议项目组人员把每次inster单笔数据改为改为多笔同时commit，500笔一次，然后重新压测，发现能支持更高并发游湖，而且TPS也上去达到预期指标值，具体抓取如下问题分析。

1.1  表面性能问题监控

监控发现数据库服务器磁盘IO写入一直偏高，如下图：

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

1.2 内核问题定位分析

通过与开发人员分析，因为T0交易在高并发下线把数据写入到过程表，这时在通过业务查询功能，查询出对应的过程表数据，通过促发for update，进行查询更新到目标表。我们通过时时关注过程表数据增加量与被更新到目标表，移除量，就是看例如每秒增加10000笔下，一次性能被更新一刀目标表数据量有多少表，例如在高并发过程表数据都能维持在100笔，而且在停止并发时，过程表数据能及时被更新迁移到目标表，说明处理能力可接受，如果更新迁移到目标表时间一直小于过程表增加速度，说明并发数高或者能力处理有问题，因出现问题才会建议项目开发人员 每次500笔commit一次，来提升TPS 和数据插入处理能力。

而在过程表数据量逐渐增加情况下，前端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%，资源利用率也上去了，终于大功告成。

我们的攻坚团队

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

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

作者：郭柏雅（泊涯）

拥有13年软件从业经验，12年的金融项目性能实施管理与测试质量控制咨询经验，通过相关行业的开发和高级测试认证，例如SQL SERVER开发认证，高级软件评测师认证等。

2010年加入上市公司高伟达集团公司，具有8年测试团队建设管理经营经验，先后在不同城商行的项目担任过性能测试优化专家、项目群测试管理、企业级IT测试质量控制管理规划咨询建设，其中包含，建行、兴业银行、鄞州银行、唐山银行、华夏银行、泉州银行、厦门银行、四川农信等商业银行以及烟草系统、ERP制造业、医疗等项目，也经常到高校分享职业发展技能知识和厦门本地其他企业生产性能故障分析优化支持，例如典型案例如下：

     2006年，参与某国有大行26亿信贷项目建设的性能测试；

     2007年，参与某国有大行证券交易管理系统性能测试；

     2008年，参与某国有大行卡系统日终处理性能测试与优化；

     2009年，参与某国有大行所有系统用户统一登录认证（单点登录系统）性能测试与调优；

     2010年，参与某国有大行当时第一个且数据量最大解决巴塞尔协议的风险加权资产类项目，并获得银行业科技三等奖

     2014-2016年，参与某国有大行新一代800亿级项目，负责该行四大重点项目中的信贷与客户管理项目群的非功能测试咨询与性能故障分析优化和功能测试管理支持工作；

     2017年，负责某城商行IT质量规划建设咨询，负责质量测试管理咨询。