高性能WEB开发的性能调优（四）——程序调优

经过上述系统调优，虽然吞吐率有所提升，但我们也面临了新的瓶颈。由于各种系统资源都没有被用尽，甚至系统很“空闲”，所以靠增加CPU，内存，线程，连接池大小等方法都没有效果，我们认为，此时瓶颈存在于代码当中。

一、问题排查方法

为了确定代码中的瓶颈，我们采用了以下两种方法，配合上一节中讲到的各种系统监控，以期找到代码中的瓶颈：

1、打印各代码块的耗时日志

为重要或者复杂的逻辑、IO等操作记录运行时间，根据时间定位瓶颈所在区块。

2、对瓶颈所在区块，采用逐行注释的方法，排查性能瓶颈

将可能是瓶颈的代码行注释掉，再反复进行压力测试，逐个排查。

二、问题排查步骤

采用上述方法，我们进行了以下排查：

1、打印系统各个环节的耗时，发现对原有系统的用户信息查询（含dubbo通信）速度较慢

1）注释掉dubbo调用，不使用用户信息查询，系统性能大幅提升

2）注释掉原有系统dubbo调用的方法体，改为空调用，性能大幅提升，排除了dubbo框架本身的性能问题

结论与改进方法：此处瓶颈为原有系统用户信息查询本身的性能，通过优化查询的逻辑来提升性能

2、打印系统各个环节的耗时，新系统的下单功能速度较慢

1）注释掉数据库插入操作，系统性能大幅提升，tps上升到3000以上

2）注释掉消息队列的入队操作，tps上升到1800，数据库连接池的使用量上升到10左右。

结论与改进方法：经过详细的耗时日志和代码走查，发现数据库插入操作已经达到最简，每次写入耗时仅占1~2毫秒，无法再进行精简。而消息队列也已经采用线程池管理，进行异步消息发送，代码层面无法再进行太多优化，为了提升性能，我们决定改变系统实现逻辑，用对账来取代消息队列，直接去除消息队列的操作。

3、关闭log4j日志

由于没有什么明显的耗时操作，每个事物的耗时都在10ms以下，所以尝试关闭日志，用同样的方式进行压测。令我们意外的是，tps上升到了3000，数据库连接池使用量上升到280左右，服务器线程数2400几乎被使用完，可以说系统的性能和资源利用率有了质的提高。

这里要说明两点：1）我们开启了本地代码info，第三方控件warn级别的日志，2）日志采用了缓存写入，每16K写入文件一次

三、日志问题

应该说日志已经尽量做到了精简和优化，因此日志带来的性能大大出乎了我们的预料，我们不得不花费功夫来专门进行日志的调优。日志调优主要向两个方面努力：

1、减少不必要的日志

尽可能的只在入口，部分出口和异常的时候才打印日志

2、使用更优秀的日志框架

经过查看，目前主流的日志框架除了log4j，还有出自log4j原作者之手的logback和log4j2。既然更换日志框架，肯定希望换最好的，于是我对三者进行了简单的性能测试，对同样的长度为50的字符串向文件输出5万次。实测成绩如下：

log4j：8.2秒

logback：1.3秒（配置了buffer+异步输出）

log4j2：1.5秒（配置了buffer+异步输出）

经过简单的测试，我们选择了性能最佳的logback，此外，logback配合日志门面slf4j，为将来的升级提供了便利。