由于这一年主要都在做针对分布式块存储的性能调优，从刚开始接手毫无头绪，脚踩西瓜皮似的想到哪定位哪，到后面有章法的去排查调优，再到现在提供了一套完整性的排查工具协助前场快速定位性能问题等等... 在这里做一些阶段性的总结，希望能够捋清楚自己的思路，也期望能够发现一些之前忽略了的盲点。 暂定结构如下：
- 性能调优为什么重要、这件事为什么是不可忽视和必要的
- 为什么性能调优难、性能调优面临什么现状
- 在工程开发中性能调优人员需要做什么事、并且针对这些难点应该怎么去解决
- 根据经验事后总结出来的方法论，并且说明为什么这么做，合理性在哪
- 根据总结的方法论，分部分、分模块的进行阐述，每个模块有哪些方法可以使用、优先级如何
- 给出具体的调优例子、阐述方法论和具体排查手段是这么生效的
- 提供自动化建议、怎么搭建自动化排查工具
- 展望以及未来将要做的事
另外、对于性能调优、我是悲观的、因为整个系统太复杂了，涉及的东西太多了，即使积累了一年了，当用户反馈出现性能问题的时候，我也没自信拍着胸脯说自己100%解决(当然对外表现出来肯定得游刃有余的)，我认为我所做的总结，能够指明一种方向，按照这种方向，按照我的方法，相比不用之前应该能达到如下效果：
- 对分布式块存储的整体性能上限有所优化
- 出现性能问题的时候有法可依，有具体的排查思路能够快速响应
- 随着积累，对于性能问题各种方面的影响程度会越来越胸有成竹，定位问题也会越来越快
为什么性能调优重要
- 用户体验：性能优化可以提升用户体验(很多国企等公司非常关注性能，性能是影响采购的重要指标之一)。在满足可靠性的前提下、一个优秀的用户体验的产品，更容易在竞争中赢得优势，进而才有可能促进“大卖”产生收益反过来养活程序员团队。
- 资源利用率：性能调优可以提高系统的资源利用率。减少资源占用或改进系统设计，可以减少计算资源、内存、存储和网络带宽的无效使用、提高单位时间内能够干的活、相当于变相降低系统成本。
没错，两个都跟技术没关系，说白了就是一个能赚钱一个能省钱。
为什么性能调优难
性能调优容易面临困境
不知道有没有人跟我一样遇到过这种困境： 刚开始的接手这个任务的时候我经常会陷入迷茫： 我们在整个软件系统的IO路径的通信的地方做了统计、并且我也积累了一些可以排查的手段和思路，但是往往换了一套环境之后整体性能变差了很多，我积累的一些排查指标全部显示异常，但是指标往往太多了，根本不知道从哪里开始看起，而且很容易蒙头乱撞，到最后往往花了时间，效果也不好。
难1:系统的复杂性&&影响因素多
整个系统，尤其是分布式系统的运行过程需要多种模块的参与，一个IO从前端接受到后端处理到真正落盘，从节点来看，服务器上的操作系统、CPU、内存、网卡等等都有参与，除了这些各式各样的硬件之外，软件中的各种组件、子模块通常也囊括其中，这样就会导致可能的因素有很多，甚至会出现多种因素联合作用导致性能差的问题，导致问题定位起来无从下手
难2:所需要的知识范围跨度广
因为系统足够复杂，影响因素足够多，并且每个因素都有可能独立或者联合作用在性能表现上，所以你必须在很宽泛的角度了解分布式软件每个模块基本原理，IO的路径，计算机处理的基本流程、操作系统各类调度的原理、内存访问的流程等等... 根据目前出现过的问题来看，这类知识几乎都非常重要，目前来看只能慢慢积累，因此性能调优有经验和没经验差距会很大
难3:有时候可能多个问题同时出现
在真实的性能问题排查中、整个系统的性能瓶颈可能不止一处，可能有5处，但是你必须识别影响最大的因素，否则就可能出现，我明明找到异常了，我也解决了，但是整体性能还是没有提升，久而久之就开始怀疑自己是不是根本看的地方不对(实际上是对的但是不是最瓶颈)，甚至开始怀疑自己的能力，从而进入恶性循环 举个例子： 当你发现性能差、这个时候整个系统可能同时如下问题： 1、有某个磁盘反应很慢 2、内存条只插了一个 3、网卡也只插了一个
如果不遵循一定的方法论、你突然发现了，有某个磁盘慢了，你把它换了，磁盘正常了，但是整体性能没有提升，因为很可能这个时候由于内存条不够进而导致内存带宽不够，cpu可能有过剩的处理能力但是它卡在读写内存的瓶颈上，导致整个流程的某个环节达到瓶颈，磁盘慢当然是问题，但是不是主要问题。
难4:可观测性差
前面也提到了，出现问题的时候往往很多指标同时异常，那么如何准确识别这些异常，按照什么顺序什么思路排查这些异常，什么阶段看什么异常就显得格外重要
综上、一个完善的，有逻辑的，能够提供实际指导意义的方法论是非常重要的。
