问题排查思路

按照从发起到接收到响应的各项服务以及接口顺序，针对性的调用单接口一层一层排查。

1. 发起端的CPU/带宽/系统文件可打开数；
2. 中间件Nginx的各项配置，查看性能测试执行时Nginx的最大等待时间；
3. Tomcat的CPU/带宽/数据库连接数/系统文件可打开数，查看服务器实际处理请求的最大时间与Locust记录的时间是否一致；
4. 第三方服务（如：Mockserver）的中间件Nginx的各项配置；
5. 第三方服务的CPU/带宽/系统文件可打开数/数据库连接数；
6. 从第5步开始回写到请求端的各项指标，依次从5再检查到1。

心得总结

1. 负载发起端的整体性能要好于被测端，至少保证测试结果没有受发起端瓶颈影响，。
2. 所有的不能理解的异常，都是有原因的，并且应该找到。
3. 遇到问题时，尝试分块排查，锁定问题范围。
4. 测试过程中，从请求发起前到接收到返回后，涉及到的任一环节都有可能有瓶颈。例如：Linux系统支持打开的文件数/Uwsgi支持打开的连接数/Nginx配置/带宽/CPU
5. 性能测试工具不仅要会用，还要足够了解它的原理，需要完全理解测试过程。