- 一切优化要基于确切的报告，而不是靠猜。
- 我们只有通过压力测试才能知道程序性能几何。
压测前准备
我们应对单台应用服务器做压力测试，你只有知道了单台能够承受多少才能知道集群能承受多少。
然后要确定单台应用服务器性能目标：
- 吞吐量，每秒处理多少请求
- 延迟，平均、P50、P90、P99的请求在多少时间内完成
如果客户要求吞吐量为2000rps，能提供2台服务器，那么每台的吞吐量则为1000rps。
如果客户要求延迟P99 <= 2秒，那么和服务器就没有关系了，你需要优化程序算法。
压测时的观察和调优
下面我们对单台应用服务器开始压力测试。
保证CPU用满
压测期间我们首先要保证的是CPU利用率接近N * 100%（N为CPU核心数），如果CPU利用率不满那么压测报告就没有意义，因为机器并未全力运转。
发现CPU没有用满，那么有这么几种可能
- 压力太小，可以调整压测工具来做到
- 线程阻塞，后面会讲
保证CPU花在非GC上
好了现在CPU用满了，那么我们要通过jstat -gcutil来观察JVM是否把CPU花在了GC上，你也可以添加-XX:+PrintGC -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:/path/to/gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=1 -XX:GCLogFileSize=20M JVM参数得到更详细的GC日志。
重点关注Full GC的次数和占用时间，如果发现Full GC很频繁，有三个解决思路：
- 增加内存
- 优化算法，降低内存利用率，可以通过jmap导出内存dump，再使用MAT分析
- 降低压力，可以是降低压测工具侧的压力，也可以是调小程序自身线程池
解决阻塞
用jstack导出thread dump来分析。
线程阻塞是常见的CPU利用率不满的元凶，因为阻塞时不占用CPU，你可以在压测期间用jstack收集几次堆栈数据，然后观察里面的BLOCKED、WAITING、TIMED_WAITING状态的线程的堆栈，找到线索。
如果发现阻塞不可避免，那么可以通过增加线程数的方式来利用CPU。
如果阻塞发生在连接池相关，那么调整连接池大小。如果阻塞发生在执行SQL有关，那么优化SQL语句。如果阻塞发生在其他地方，那么做针对性优化。
观察慢SQL
慢SQL是常见阻塞原因，找出这些慢SQL，对它进行优化，或者对数据库表做优化，提升程序响应速度，提高CPU利用率。
观察执行次数异常的SQL
执行次数异常的SQL也是很重要的一点，抓住这些SQL，对代码进行优化。
数据库连接池
连接池不够也是常见的阻塞元凶，线程在等待连接池导致CPU利用率上不去，不过还是那句话，不要盲目调整，你应该在jstack里看到大量获取jdbc connection的阻塞线程之后才去调整它。
线程池
按照理论上来说，如果线程不阻塞，那么只需要N个线程就能把CPU占满（N是CPU核心数）。线程阻塞占用比例越大，就需要越多线程来占用空闲CPU时间。
如果你优化之后把阻塞比例降低了，那么你也需要相应调小线程池尺寸。
过多的线程池不会带来更多好处，白白占用内存而已。
服务器异常日志
有时候服务器异常日志也会提供给你很好的线索，记得观察。特别是如果异常特别多的话，会直接影响性能的。
观察、优化、验证的循环
当你做了一个优化点后，你再压一遍，看看是否有改善，同时需要调整其他相关参数，比如前面提到的调小线程池。
同时，有些时候做了一个优化点之后，会发现新的问题，这个问题可能在之前被那个占大部分因素的性能瓶颈遮蔽掉了，现在大问题解决了，那这个小问题就显现出来了。此时，你需要针对这个新问题再收集报告，然后再优化。举个例子，原来是SQL慢，优化好之后会发现程序算法也有问题。
评论