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

故事案例发生原因

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

测试实施场景

到客户现场后，客户开发人员很耐心的帮我讲解了业务逻辑、技术框架等以及环境情况，也介绍了目前情况，在高并发下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%，资源利用率也上去了，终于大功告成。

我们的攻坚团队

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

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