强调徒手是缺少工具和监控，强调全链路是不纠缠某段代码、业务逻辑的问题，而是需要找到问题瓶颈在哪个环节上。

场景描述

某客户通过PTS（一个打压力工具）来压选号业务(HTTP服务在9108端口上），一个HTTP请求对应一次select seq-id 和 一次insert

PTS端看到RT900ms+，QPS大概5万（期望20万）， 数据库代理服务 rt 5ms，QPS 10万+

调用链路

pts发起压力 -> 5个eip -> slb -> app(300个容器运行tomcat监听9108端口上） -> slb -> 数据库代理服务集群 -> RDS集群

问题

性能不达标，怀疑数据库代理服务或者RDS性能不行，作为数据库需要自证清白，所以从RDS和数据库代理服务开始分析问题在哪里。

app业务方也尝试过增加app容器对性能没啥提升，所以怀疑问题在数据库上

分析过程

这里缺各个环节的RT监控，所以定位不了哪个环节瓶颈了

先到app服务上抓到数据库代理服务上的包，快速确认下从app到后端有没有瓶颈，如图1

重点在如何分析图1的数据，我从图1可以得到 数据库代理服务 RT是 15ms，也就是单连接的TPS是1000/15=70, 实际一条连接一秒钟才给后面发20个请求。

所以结论是后端能扛40万 QPS，压力没有从app服务打给后端

继续在app上抓包，这次抓服务端口9108的响应时间（如图2），分析如图1，结论是压力根本就没有打到9108上

临门一脚得结论

如图2，netstat 一看就知道问题在app服务前面，总结在图4

这次只是在各种监控缺乏的场景下，如何借助最原始的手段来有理有据地甩锅，其实核心理论在图1的分析过程，也是能力的体现，这后面是对并发、RT、QPS的理解。

图1 图2 图3 图4

参考 

Learn X in Y minutes

https://learnxinyminutes.com/

10+倍性能提升全过程–优酷账号绑定淘宝账号的TPS从500到5400的优化历程

https://plantegg.github.io/2018/01/23/10+%E5%80%8D%E6%80%A7%E8%83%BD%E6%8F%90%E5%8D%87%E5%85%A8%E8%BF%87%E7%A8%8B/