记一次loadrunner 压测 tps过低问题排查

   最近大佬让我压测一个某某银行支付产品(用户扫码支付、商家扫用户二维码支付等等)，说实话刚开始是懵逼的，毕竟还是新手，后来经过高手指点说，你要先知道服务器配置，比如内存啊、硬盘啊、CPU啊、还有数据库的配置。经过一番了解以后，开始上路了！
   因为没有web页面，只能压测接口流程，所以loadrunner 我用的是Java vuser 模式，毕竟还是小兵，就拿着开发提供的模拟类各种改，终于调通了，哇咔咔激动啊。迫不及待的在controller里创建了个scenario开始配置，压多少用户呢，想着头一次就10个用户并发，跑个5分钟看看效果，咔咔咔一通配置，就剩一个点击start scenario 按钮了，啪一个点击系统开始运行，打开我们系统的日志，嗖嗖嗖的满屏刷，我靠这绝对浪费性能啊！记下来稍后调一下日志级别！

10个用户tps 到达了20左右，想着是不是并发太少了，感觉还好没毛病！

30个用户tps 还是20左右，完犊子，心慌了，不应该啊！

然后开始排查服务器cpu、内存占用情况，top命令、free命令看了一遍没毛病啊，占用的不高。难道是系统内存泄漏？jstat -gcutil prid 3s 看了一下 ygc稍微频繁、fgc正常，内存泄漏不应该应该就是jvm分配的年轻代的太少了，ygc有点频繁，卡卡改到了3个G(有点猛哈)，来再走一遍

30个用户tps还是20左右，不应该！

难道是线程池、数据库连接池配置的太少了？就对核心平台的线程池、数据连接池一顿该（都改到200了），再来一遍

30个用户tps 还是20左右，不应该！（真想骂句脏话*****）

难道是mysql数据库慢sql导致拉低了系统性能？然后就开了mysql慢sql的开关，慢sql时间设定位0.01s，走一遍

30个用户tps 还是20左右，不应该！看一下mysql打印的慢sql日志，全是insert语句跟update语句耗时0.014s左右，没有select语句没啥大毛病。

又回到原点了，太扎心了！接下来又把系统从头到尾捋了一遍，我们核心系统打印的又简要日志，看了一下没笔交易处理时间为150ms左右挺快的，感觉有个请求的数量太少了（核心系统的线程数配置的挺大啊），我们还有个核心前置（核心前置用的Tomcat 配置的线程数也挺大的啊），难道是核心前置忘核心平台请求的数量太少了？于是决定单压一下核心平台,又是一顿loadrunner脚本修改（核心前置跟核心平台接收的报文不一致），费了老半天劲，终于修改好了，开始跑起来！

30个用户tps还是到达70了，TNND终于看到希望了！

再来100个用户，tps狂升到200了，可以了！

看来还真是核心前置的问题，终于定位到了（肯定是核心前置请求核心平台请求所数不够），开发看了一下代码，核心前置请求核心平台时，每个请求都建立一个链接，导致每次新创建一个链接浪费了时间和性能，就问你坑不坑？修改完核心前置以后就走上了质的飞跃！