TPS从300笔/S到5500笔/S的测试分析优化之路

                                                                                         郭柏雅

 问题总结回顾

1.   每一次攻坚性能故障问题都是一次精喜的探险，需要清醒头脑、大局观的分析意识、扎实的专业基础等更要凝结你的意志和自信心，因为这是一个艰苦而有趣的过程。本文案例由发生至解决，通过业务逻辑的认知、测试测试环境的了解、测试脚本的准确开发、各个环境的监控分析与优化，操作系统与基础硬件设备知识的认知与优化、测试报告的编写等，从基础软件优化到架构代码优化以及测试脚本的改良，终于柳暗花明，这种喜悦是难以言表的。51Testing软件测试网SHJi3K*Y1J*E

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

故事案例介绍51Testing软件测试网]\D3q:i)`&x

 故事原因：某知名城商行代支付管理系统，因上线一段时间后客户量剧增，在生产运行过程中偶尔会出现资源争用现象，客户领导担心目前环境无法满足业务量日益增长发展趋势，得此机会我过去支持测试。

测试实施场景51Testing软件测试网US-W;E2_C~g/H

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

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

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

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

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

                           测试过程问题分析51Testing软件测试网Z"T,G&Fy+t"T

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

                        问题分析

1、数据库问题分析优化方法51Testing软件测试网 yYfX!F7G

在压力测试过程中发现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，解决高并发问题。

 51Testing软件测试网6i9p5^MR!k1{c]L

1.1 表层问题监控51Testing软件测试网m"w.L
H G9P\)P

51Testing软件测试网2zhWU [N)I

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

51Testing软件测试网@/\ g,N't

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

51Testing软件测试网7mg
xSJ

1.2内核问题定位分析51Testing软件测试网Q9x[V$Yu*Qv:l

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

51Testing软件测试网d {|3p5l

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

 51Testing软件测试网8d g{&Z}R5UqDwN

2、应用方面问题分析优化51Testing软件测试网*tt!eZ6r(BbK0~

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

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

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

这时的TPS，稳定在660笔/S，交易成功率也在99.9%，不会大批量出错现象。51Testing软件测试网B$P1S$E"X+Aqb

51Testing软件测试网(V2b$X
F [0V L$UW

 51Testing软件测试网{Zk+JS'O9_,{

性能攻坚战后期：51Testing软件测试网KKQ%h T F"xzw L

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

51Testing软件测试网!`/_,b,IQ2a(~I(]u7lV

51Testing软件测试网9Q?:{2jju5z

攻坚团队51Testing软件测试网}?4UY_Y(Z;T H

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

一个拥有高度的执行力的团队一定是一个责任分明的团队。在应对突发、严重、紧急情况时，要有专门的攻坚团队来解决这类问题，这个团队应该包括项目组的核心专业人员，有较强的动手能力和研究能力，能够变通解决问题，思路开阔。他们的作用是至关重要的，往往可能决定项目的成败。51Testing软件测试网b{^[I