小编点评

一、测试场景 1.1 限流测试场景 1.2 被测交易：查询类交易，HTTP协议 1.3 交易链路：jmeter - web - coimpre(前置服务) -- coimbp -- cobp (coimbp 、coimpre 都会访问同一个数据库) 1.4 注意事项：跨网段存在网络延迟，可能导致TPS波动情况 二、场景配置 2.1 配置coimpre 服务的限流参数 三、场景执行 3.1 执行场景使TPS 大于 限流参数，出发限流报错 3.2 通过日志以及服务返回确认是否成功触发限流 四、测试问题 4.1 监控coimpre服务CPU资源，从5% 上升至 90%以上 4.2 两次i验证执行，确认问题存在 五、排查思路 5.1 使用top命令监控消耗CPU高的进程是否为java服务 5.2 使用top -Hp pid 查看进程下的线程消耗进一步确认是哪个线程消耗 5.3 打印线程dump文件，分析dump文件查看该线程此时的业务操作 5.4 定位问题，给出优化意见，测试验证 5.4.1 通过dump文件分析，有问题的线程主要是在java net.URClassLoader.findResouce()方法 5.4.2 项目组确认，交易报错后，日志会打印错误信息并带出是哪个jar包导致的错误 5.4.3 共同认定是该问题导致的cpu升高，开发人员修改此处代码，不再遍历jar 5.4.4 修改后，重新部署版本，再次验证限流，cpu资源下降至10% 六、归纳总结 本次测试中，在高可用场景下对限流功能进行了测试。由于被测交易为查询类交易，HTTP协议，且涉及多个服务之间的调用，因此在测试过程中需要注意跨网段存在网络延迟对TPS波动的影响。通过对限流参数的配置和测试，使得在TPS超过限流参数时能够正确触发限流报错。经排查，发现限流报错是由于Java应用程序在处理请求时，线程消耗大量CPU资源导致的。经过开发人员的优化，修改了处理逻辑，减少了不必要的jar包遍历，从而解决了CPU资源过高的问题。最终，在重新部署修改后的版本后，再次进行限流测试，实现了TPS降至10%的正常水平。

正文

测试场景：高可用场景--限流测试；

被测交易：查询类交易，HTTP协议；

交易链路：jmeter - web - coimpre(前置服务) -- coimbp -- cobp （coimbp 、coimpre 都会访问同一个数据库）；

注：cobp 为合肥机房，其他服务均为北京机房，要注意跨网段存在网络延迟（会导致TPS波动情况）；

场景配置：配置coimpre 服务的限流参数；

场景执行：执行场景使TPS 大于 限流参数，出发限流报错，可通过日志以及服务返回确认是否成功触发限流；

测试问题：交易触发限流后，监控coimpre服务CPU资源，从5% 上升至 90%以上，两次i验证执行，确认问题存在；

排查思路：

　　1. 使用top命令监控消耗CPU高的进程是否为java服务，（程序为java开发）；

　　2. 使用top -Hp pid 查看进程下的线程消耗进一步确认是哪个线程消耗；

　　

 　　3. 打印线程dump文件，分析dump文件查看该线程此时的业务操作‘（第一个图是 linux下 jcmd生成的，第二个是使用的 java VisualVM 生成的）

　　

　　

   　　4. 定位问题，给出优化意见，测试验证；

　　　　4.1 通过dump文件分析，有问题的线程主要是在java net.URClassLoader.findResouce()方法，通过第一个图可以看到java util.zip,ziprile getentry，结合两个方法，并通过和开发沟通是否对某个 ZIP 文件中文件文件有操作。

　　　　4.2 项目组确认，交易报错后，日志会打印错误信息并带出是哪个jar包导致的错误，从而就会遍历整个jar目录。

　　　　4.3 共同认定是该问题导致的cpu升高，开发人员修改此处代码，不再遍历jar。

　　　　4.4 修改后，重新部署版本，再次验证限流，cpu资源下降至10%