开发运维必知的21件事研讨.docxVIP

开发运维必知的21件事：认清性能问题2014-08-08 15:50 佚名 听云 字号：T | T对于开发者、技术管理者、架构师、系统分析师和项目经理来说，创建具备高性能特征的复杂软件都是一件极其困难的事。 然而,通过了解一些基本原理、性能问题的解决和预防可以更简单、可靠。 本文讲述了这些基本原理，涵盖了一系列的目标、术语、工具和决策，综合利用好它们来最大可能的创建一个长期、有效的高性能应用。AD： WOT2015 互联网运维与开发者大会 热销抢票今年越来越多开发者开始关注移动应用性能管理和性能监测，我们找到一位国外资深的开发者对性能的相关理论，希望各位喜欢。1. 公理化方法当我在1989年加入 oracle 公司时，解决性能问题（人们通常说的 oracle 调优）是很困难的。 只有少部分人声称他们很擅长这个，很多人都去咨询他们。 当时，我进到 oracle 调优这个领域时，我完全没准备好。 最近我又开始对 mysql 进行调优，这看起来和我20年前在 oracle 公司做的差不多。它让我想起了当我13岁刚接触代数学时是多么的困难。 在那个年龄我只能依靠“数学直觉”来解决类似 3x + 4 = 13 这样的方程。 问题是我们之中大部分人都没有所谓的“数学直觉”。 我记得当看到这样的问题: 3x + 4 = 13 求解x，只能采用试错法偶然发现 x 应该是3。试错法给我的感觉虽然能解决一些简单的方程式，但很慢而且不爽。 一旦等式稍有变化如 3x + 4 = 14，试错法就不能适应。 那么该怎么办呢？当时我没有好好思考过，直到15岁时James R. 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. 吞吐量通常来讲，响应时间和吞吐量是一个倒数关系（响