性能优化总结篇

参加工作十一个年头了，从最初为团队的慢SQL做性能优化，到主导推动压力测试完成性能指标，再到后来紧急救火处理各类线上性能问题，我想对常见的性能问题及其分类在此也做个总结。有些人认为做性能优化并没有那么复杂，不就是做压力测试吗，然后哪里有性能瓶颈就解决哪里不就可以了吗？然而现实情况并不会如此简单，比如系统可能是遗留的老系统，也或者耦合过多不做一定的改造很难单独某个模块进行压力测试，甚至是压力测试中性能表现很好但线上却出了问题。在进行性能优化前你要对系统有个全局的认识，解决手段通常按紧迫程度也可以分即时参数调优类、短期编码救急类、长期架构优化类。

参数调优类按最常见出问题的顺序可分为：
JVM参数调优、数据库连接池调优、Tomcat并发线程数等调优等

短期编码救急类的按出问题的顺序可分为：
慢SQL、不合理的循环操作、不合理的线程（池）模型、不合理的超时设置等

长期架构优化类的按出问题的顺序可分为：
应用单点设计、数据库单点设计、未异步化、长任务同步接口设计等

JVM参数调优可参考《JVM垃圾回收那些事》
数据库连接池调优不同的连接池实现会有所不同，当然不同的连接池性能也差异不小，可自行搜索主流连接池性能基准测试结果对比
其他各类中间件的参数调优可参考阅读各中间件的user guide文档。
参数调优类性能优化见效最快，只要不是用了很偏门的中间件，一般常见的配置问题也能在互联网上找到公开的答案。

慢SQL，这是在我的职业生涯中碰到的最为常见的性能问题。如果你是创业类公司，如果你们团队缺少Mysql方面的资深开发人员，我的建议是先用Oracle。 在Mysql知识缺乏的情况下使用它的风险在于：达到一定的数据量后，你需要不停地做很多SQL层面的性能优化（建索引啊 etc...），而且这个数据量绝对会比你认为的那个数小很多。使用Oracle的风险在于：未来将面临版权问题。但却赢得了时间去完善业务，即把性能优化的时间推后，前期赢得更多的实现业务的时间。Mysql性能优化可参考
《高性能Mysql》
不合理的循环操作，比如在循环内进行数据库查询、网络请求、IO请求等操作，这也是新手程序员易犯的错误之一。
不合理的线程模型，常见的是没用线程池，或者线程池过多/过大，导致运行时线程数超过资源上限。
不合理的超时设置，主要体现在一些服务调用、HTTP调用时不注意超时设置，对方不可用时导致堵塞后引发雪崩。
短期编码救急类性能优化见效时间中等，需要推动相关开发人员进行代码调整，甚至为了定位性能瓶颈需要在代码中打印各步骤的耗时。

长期架构优化类的见效时间最久，成本也最高，通常配合着系统重构进行。可伸缩性的架构设计，要求接入层、应用、中间件、数据库都是可伸缩的，当然，应用的可伸缩紧迫性通常排在首位。在做伸缩性设置时有一些常见的坑需要避免，如：附件处理、本地（进程）缓存数据、应用会话。要保证你设计的应用架构是符合分布式设计的，通常新建的系统较好处理，对旧系统进行分布式架构重构时稍不注意便会踩坑。另外一个常见的架构优化手段是异步化设计，利用消息中间件进行削峰填谷。架构设计可参考本blog关于架构设计的其它文章https://www.cnblogs.com/mzsg/tag/架构/

其它性能优化的手段可参考本blog关于性能优化的文章https://www.cnblogs.com/mzsg/tag/性能优化/。好了，如果你对性能优化有其它疑问，可在评论区讨论。如果你有关于性能优化的培训或咨询需求，也请站内信联系我。