1回答

风落几番

2019-08-07

已采纳

这个要结合后边的监控去分析。我举几个例子：

Round 1 ： 响应时间慢

这恐怕是我们遇到最多的场景，直观上看过去就是响应的非常慢。这个时候我们的调优方式就是把整个的Response Time（RT）通过日志进行不断的分解，例如我们现在是把一个RPC（Dubbo）的服务部署在Tomcat中，上游用Nginx做反向代理。在这样的架构下，一个完整的RT就会包括前端RT、网络传输时间、Nginx RT、Tomcat RT、Dubbo服务RT和数据库RT。如果存在问题，我们可以请开发配合在各个局部增加日志，观察具体响应时间慢的点，从而进行后续的优化动作。

Round 2 ： TPS波动大

一般来说，性能测试的TPS应该随着并发量的上升而呈跟随上升趋势直至稳定，但是有时候我们会发现，被测系统的TPS非常不稳定，上下波动非常大。排除网络可能造成的影响，在实际测试过程中可能遇到最大的可能就是：被压测服务器上存在其他运行的服务争抢资源或者垃圾回收的问题。

其中后者的可能性居多，一般都是出现有频繁的FGC。这就是需要我们结合着对JVM监控的数据来进行分析，修改JVM内存参数或代码逻辑，达到优化的目的。

Round 3 ： 开始加压正常，到某一个点突然开始出现错误，并越来越多

这种情况多数可能是由于服务器、中间件等配置的线程数、超时时间造成的影响，线程数过小，服务端同时可以处理的请求就少，自然到达一定的并发就会等待，最终超时错误。

Round 4 ： 并发数增加，TPS不增加，CPU内存利用率都不高

这类问题我遇到过的更多时候是由于数据库的慢SQL或者不恰当的代码或数据库锁机制造成的。一般优先排查数据库SQL问题，通过数据库日志判断SQL执行时间，查看是否需要优化；如果SQL没有问题，那么就需要与开发同学一起沟通确认代码中是否有不恰当的同步锁等等。

这是我还没上线的一个专栏中写的~~暂时可以先放出来回答你这个问题

1

3

forkey

回复

风落几番

好的，ok，到时候我也去学习学习

2019-08-08

共3条回复