然而事情并非如此顺利结束，在接口测试进行回归的时候，测试同学发现事件运算接口TPS不管怎么压都只有三四十，当时看到这数据就傻了眼，要知道以前压的时候是400+，相差了10多倍，赶紧检查数据库，环境配置，没发现任何异常。没有办法只能再次打开Jprofile再次压测进行监控看看能不能捞到些有用数据， 在CPU报告上发现一个非常可以的方法bsh.Interpreter.eval（）占了我72%的CPU,具体情况如下图（当时忘记截图了，将就下看山寨版CPU图吧！）：
这个方法在程序中是来支持一些脚本注入运算的，为了进一步确认是否是此方法导致TPS上不去，找出该代码把脚本引擎调用用的地方直接替换成一个固定值1给以前的调用方，再进行压力测试，果然不出所料TPS飚到正常水平，问题算是定位出来了，后来了解到使用bsh引擎的原因是由于在其它接口性能测试中发现以前使用的MVEL脚本引擎存在内存泄露，靠，怎么都有问题！网上查了一些MVEL相关资料，感觉应该可以避免，不管怎么样先试试，先确认下MVEL会不会有性能问题，直接把以前的代码回滚到使用MVEL的版本，如下所示：
|
public Object computerRUM(Map<String,Object> eventInfo, RumDO rumDO) { String expresion = rumDO.getExperssion(); Serializable expressCompilor = getCompilorFromCache(expresion); if (expressCompilor == null) { Serializable expressCompilor = MVEL.compileExpression(expresion); } Object result = MVEL.executeExpression(compiled, eventInfo); return result; } |
