开发运维必知的21件事：认清性能问题今年越来越多开发者开始关注移动应用性能管理和性能监测，我们找到一位国外资深的开发者对性能的相关理论，希望各位喜欢。1.公理化方法当我在1989年加入oracle公司时，解决性能问题（人们通常说的oracle调优）是很困难的。只有少部分人声称他们很擅长这个，很多人都去咨询他们。当时，我进到oracle调优这个领域时，我完全没准备好。最近我又开始对mysql进行调优，这看起来和我20年前在oracle公司做的差不多。它让我想起了当我13岁刚接触代数学时是多么的困难。在那个年龄我只能依靠“数学直觉”来解决类似3x+4=13这样的方程。问题是我们之中大部分人都没有所谓的“数学直觉”。我记得当看到这样的问题:3x+4=13求解x，只能采用试错法偶然发现x应该是3。试错法给我的感觉虽然能解决一些简单的方程式，但很慢而且不爽。一旦等式稍有变化如3x+4=14，试错法就不能适应。那么该怎么办呢？当时我没有好好思考过，直到15岁时JamesR.Harkey指引我走上正确的道路。Harkey先生教会我使用公里方法来解决代数方程问题。他给我们展示了一系列的步骤（还给了我很多家庭作业进行练习）。做作业时除了记录下这些步骤，还要写下我们是如何思考的。这样我们不仅自己想的很清楚，而且通过一系列可靠的，可重复的步骤来向阅读我们作业的人证明了我们确实搞明白了。Harkey先生看到的我的作业像下面这样：3.1x+4=13待求解方程3.1x+4-4=13-4减去相等的值3.1x=9加法逆运算，化简3.1x∕3.1=9∕3.1除以相等的值x≈2.903乘法逆运算，化简求解这就是Harkey先生教导的适用于代数学、几何学、三角学和微积分的公理化方法。由一系列符合逻辑的、可证明和审计的小步骤组成。这是我第一次真正从数学中学到的东西。自然，当时我没能认识到其中的价值，但证明作为一种技能对我后来的成功至关重要。我发现在生活中，知道一件事很重要，但能向别人讲清楚（证明）更重要。没有好的证明技能，就很难成为一名好的顾问、好的领导甚至好的员工。我在上世纪90年代中期的目标是为oracle性能优化创建一套类似的、严格的公理化方法。后来我将其扩展到了oracle之外，建立了一套适用于所有计算机软件性能优化的公理化方法。好吧，我发现并非所有人都喜欢这种说法，那我们换一种说法：我们的目标就是帮助你想清楚如何优化你的软件系统性能。2.什么是性能？假如你去google下performance这个关键字，可能会得到5亿个链接。其中涉及的内容范围可能从自行车比赛到可怕的员工审查流程（如今很多公司已经学会了避免这个流程）。但假如我去google下performance这个关键字，大部分的首页链接都会与这篇文章的主题有关：计算机软件执行无论何种任务所花费的时间。任务这个词是一个很适合的开始。任务是一个面向业务的工作单元。任务能够嵌套：打印发货单是一个任务，打印一张发货单（一个子任务）也是一个任务。当一个用户说起性能时，他通常指的是系统执行一系列任务所花费的时间。响应时间是任务的执行时长，用每个任务的时间来度量，像：每点击秒数。例如我用google搜索关键字performance的响应时间是0.24秒。这个数据来自我的浏览器渲，它渲染完google网页花费的时间，那么很明显，这量化了我对google性能的直觉感知。一些人对另外一个性能指标很感兴趣：吞吐量。吞吐量是在一个特定时间段内完成的任务的计数，例如：每秒点击数。通常为一群人提供服务比为个别人提供服务的人更关心吞吐量。例如，一个独立会计会更关心日报的响应时间是否会导致今晚需要加班，而会计部的经理更关心系统的是否能支撑所有的会计处理完今天的数据。3.响应时间VS.吞吐量通常来讲，响应时间和吞吐量是一个倒数关系（响应时间越长吞吐越低），但这并不确切。实际情况更微妙、复杂一些。例：假如，在一些性能基准测试中，你的系统的测量结果是每秒能处理1000个任务，那么用户的平均响应时间是多少？你可能会说平均响应时间等于1/1000=.001秒/每任务，但它真不是这样的。假如在你的系统内部拥有1000个相同的、独立的、并行的服务执行通道，每个通道都在等待请求到来并提供服务。在这种情况下，每个请求其实花费了1秒。现在我们知...