1.背景

   大家最近还好么，截止目前新型冠状病毒累计确诊病例已超7万4千多例，希望大家无论是在家办公还是单位办公，一定要注意自我防护。今天跟大家分享一下，最近一次真实生产压测遇到的问题，如题：if controller，本次它是主角。

2.目的

    下面进入正题：本次主题是与If逻辑控制器有关，相信有些同学对这个逻辑控制器使用非常熟练。那么这个逻辑控制器到底有什么问题呢？本期宝路就来分享下一次真实生产压测遇到的坑。

伪脚本结构图：

从脚本结构图看出：逻辑性很强，前交易成功才会执行后交易，判断是通过逻辑控制器来实现的。感觉脚本很完美。。。然而在压测过程中却出现了不合乎常理的现象。生产压测结果：

TPS趋势图：

RT趋势图：

恩？RT、TPS趋势图对应关系不对啊。。。。压测过程中TPS呈现逐渐下降趋势，RT趋于平稳，继续增加并发用户数，RT变化不明显，TPS仍呈现逐渐下降趋势。（正常现象：随着并发用户数增加TPS增长，响应时间不变或略有增长；或TPS增长不明显，响应时间增长明显）

开发人员从服务器的日志分析得出：各交易耗时很短，服务器压力并不大。这就有点尴尬了，于是乎就开始了各种排查， 最后由于时间紧迫，最后被迫使用LR11现场编写脚本进行压测。恩？LR11压测却没这个现象，然而LR11并不支持JDK1.7，这也就导致部分重点交易未压测。

回去之后，宝路这边就开始分析到底是什么原因导致这个奇怪的现象。先想着看看能不能复现，如果能复现问题就好解决了。

思路：保持脚本整体结构不变，采用JMeter官方自带的Java Sampler代替原脚本中的sampler，当然如果能自己手写Java Sampler也可以不采用官方自带的（JMeter均采用相同的3.1版本）。大家要自己写Java Sampler的话，可以参考宝路的写的：

为了简单快速验证，我先替换一个请求进行验证（其余请求暂时屏蔽），测试结果：

TPS趋势图：

RT趋势图：

哈哈，复现了。。。。紧接着，我把if逻辑控制器禁用掉并将下面的Sampelr复制到f逻辑控制的上层，大家自行脑补，就不占图了，测试结果如下：

TPS趋势图：

RT趋势图：

从复测结果可以出：TPS、RT曲线 非常稳定。对比两次结果可以看出，问题出在了if逻辑控制器。一开始我怀疑是不是我脚本中的if逻辑控制器使用方法有问题，检查了下，也网上搜了搜相关资料，没啥毛病啊。。。。。

此时给我的感觉就是JMeter3.1版本的if逻辑控制器有严重的性能问题。下篇文章给大家具体分析if逻辑的源码及性能实验验证。