系统性能优化的目标就是“更高，更快，更强”。系统性能优化是每个工程师都可能遇到的问题。这个问题非常容易理解，所以不管是技术人员还是非技术人员都可以就此谈谈自己的见解。系统性能指标通常都可以转换为一个数字，例如：高铁的平均时速为380公里/小时，GDP增速要超过10%，IOPS要达到100万，开机时间要少于10秒。可是，如果只是一味的追求数量，而要不顾及质量，甚至要牺牲质量，那将走向一条充满风险的不归路。片面追求数量的典型例子包括中国的GDP、高铁、论文等。        系统性能优化可能存在于产品的不同阶段。例如系统部署后的性能优化、系统开发后的Benchmark测试、系统开发中的性能对比也优化。所有这些优化看起来粒度不同，目的也不同，但是都有章可循。粗略的说来，提高性能要遵循的一般步骤为： 1、确定系统性能的度量指标。 2、确定如何测量系统性能的度量指标。 3、如果测量出来的指标已经达到要求，则继续步骤7。否则继续步骤4。 4、寻找系统性能的瓶颈。 5、消除系统性能的瓶颈。 6、测量改进后系统的性能。继续步骤3。 7、结束。

第一步，确定系统性能的度量指标。这是最基础的也是最先要做的一步。试想，如果我们连什么叫性能好，什么叫性能不好都搞不清楚，后面的事情将怎么开展？确定指标需要根据具体的工作来定。例如业务要求的可能是提高某个具体业务流程的性能，也可能是针对某个测试集的性能。常见的性能指标有某个业务流程的响应时间，整个系统的吞吐量等。

第二步，要明确如何来测试系统的这些指标。度量指标必须明确并可以比较容易的测量，千万不能弄成德育指标。

第三步，略。

第四步，寻找系统性能的瓶颈。这一步非常重要，也是实际系统开发中最花费脑力的一步。所谓的瓶颈，就是在它上面做改进之后，使得度量指标可以得到最大改进的部分。假设我们要优化总体执行时间，某一个模块的执行只占整个时间的1%。假设我们费了九牛二虎之力，将它提高了十倍，则整体的执行时间才提高了：1 - (1%/10 + 99%) = 0.9%。这不是我们想要的结果。         第五步，消除系统性能的瓶颈。如果前一步做得很准确，这里就是对症下药了，有可能需要较多的体力劳动，投入较多的开发时间。         第六步，测量改进后系统的性能。至于我们在第四步找到的是不是瓶颈，在第五步开的药方到底对不对，还需要测量和分析来验证。很多时间，寻找性能瓶颈、消除系统性能瓶颈都不是一件一蹴而就的事情，需要来来回回折腾很多次。         系统性能优化的范围可能很大（例如从处于上层的应用的角度考虑），也可能很小（例如从系统中某个具体的小模块去考虑）。考虑的范围越大的时候，可能的优化方法就越多。例如对于一个已经部署完毕的Web应用，用户可能并不关心你是从应用逻辑、数据库、操作系统、网络、存储的哪个层次做的优化（不过实际应用中数据库的调优余地可能最大）。对于Exadata等盒子类产品，用户关心的是TCO，更不管里头哪些地方做了优化。