- TPS上不去的原因分析（带宽、中间件-缓存、消息队列、线程池、连接池、异步、慢sql、单表数据量过大（目前订单表最多2个多亿条记录）、应用服务器资源、压力机资源）：
- 第一个原因：性能测试是从客户端向服务器发起一个请求，要经过网络传输，所以第一个原因可能是网络瓶颈，例如网络不稳定或带宽不够，那么同一时间点的请求量上不去，对服务请求的压力上不去那么这个TPS也就上不去。
- 第二个原因：客户端请求与服务器建立链接需要有连接池，连接池有两种 一种常见的是应用连接池，一种是数据库连接池。 应用连接池一个连接建立起来需要用连接通道，如果这个连接通道不够宽不够大，那么连接池可能不够用，导致服务器的性能利用不起来，也就是说应用连接池太小了。
- 第三个原因：数据库连接池，应用要与数据库交互时需要用到数据库连接池建立连接，如果数据库的连接池比较小的话，那这个查询速度也比较慢，数据库的综合能力跟不上，也会导致tps上不去。
- 第四个资源回收机制是否合理：连接建立起来要进行运算，运算要消耗资源，如果占用资源不能及时回收利用，会导致资源不够，这时tps也上不去。资源一个是硬件资源不够(cpu,内存)
- 通常所说的服务器tps值，默认的是http、https协议。但现实中还有websocket协议，如果同一个功能即能用http协议又能用websocket协议实现，那么websocket协议性能要比http协议大很多，tps也就大很多
- 性能测试要求的并发量很高，有时需要有做分布式的压力机，如果压力机的资源不够，或压力机的分配不合理，那么tps也上不去，服务性的性能体现不出来
- 代码逻辑复杂，代码不够简洁
- 还有服务器的架构和缓存机制，也会影响tps
- 性能是否满足的关键指标
- 第一步看错误率是不是超过0.1%，如果超过，认为性能不能满足要求
- 第二步看响应时间有没有超过1.5秒，如果平均响应时间超过了1.5秒，认为性能不能满足要求
- 第三步看服务器的cpu、内存、io 的使用情况 ，这些平均利用率有没有超过80%，
- 如何定位网络问题
- ping 命令查看下网络延迟时间，如果延迟时间很长可以断定网络问题
- 如果Ping命令延迟时间低，这时使用tracepath看路由信息
tracepath www.58.com
1: 192.168.2.10 (192.168.2.10) 20.150ms pmtu 1500
1: unknown (192.168.2.1) 9.343ms
2: 221.6.45.33 (221.6.45.33) 34.430ms
3: 221.6.9.81 (221.6.9.81) 19.263ms
4: 122.96.66.37 (122.96.66.37) 54.372ms
5: 219.158.96.149 (219.158.96.149) asymm 6 128.526ms
6: 123.126.0.66 (123.126.0.66) 138.281ms
7: 124.65.57.26 (124.65.57.26) 166.244ms
8: 61.148.154.98 (61.148.154.98) 103.723ms
9: 202.106.42.102 (202.106.42.102) asymm 10 78.099ms
10: 210.77.139.150 (210.77.139.150) asymm 9 199.930ms
11: 211.151.104.6 (211.151.104.6) asymm 10 121.965ms
12: no reply
13: 211.151.111.30 (211.151.111.30) asymm 12 118.989ms reached
Resume: pmtu 1500 hops 13 back 12- 若报连接数不够或连接异常，不是网络问题，发起方的端口配置问题
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
