推荐序2

收到侠少的邀约来写序，多少有点忐忑和紧张。忐忑是因为平时太多时间总是在解决各类问题，没有时间好好沉淀下来读一读书，总结一下发现问题和解决问题的方法；紧张是因为我好像很久没有写字了，上一次写长篇大论还是N年前，怀疑自己是不是能够在有限的文字内把系统性能的问题解释清楚。于是，就在这样的背景下，我从出版方那里拿到了书稿，迫不及待地读了起来。

书的作者Gregg 先生是业内性能优化方面大名鼎鼎的人物，早年在Sun 公司的时候是性能主管和内核工程师，也是大名鼎鼎的DTrace 的开发人员，要知道DTrace 可是众多trace 类工具中最著名的，并且先后被移植到了很多别的OS 上。书的全篇都在讨论性能优化，我想了想，我每天从事的工作不就是这个吗？SAE 上成千上万的开发者们，他们每天问的问题几乎全部和性能相关：为什么我的App 打开比较慢，为什么我的网站访问不了，怎么才能看我的业务哪个逻辑比较慢？对于这些问题，其实难点并不在于解决它，最难的在于发现并定位它，因为只要一旦定位了故障点或者性能瓶颈点，解决起来就并不是很复杂的事情。

对于性能优化，最大的挑战就是性能分析，而性能分析要求我们对于操作系统、网络的性能要了如指掌，明晰各个部分的执行时间数量级，做出合理的判断，这部分在书中有很详细的讨论，让读者可以明确地将这些性能指标应用在80:20 法则上。

工欲善其事，必先利其器，了解系统性能指标后，就需要找到合适的工具对可能存在的瓶颈进行分析，这要求我们具备全面的知识，涉及CPU 性能、内存性能、磁盘性能、文件系统性能、网络协议栈性能等方方面面，好在本书详细介绍了诸如DTrace、vmstat、mpstat、sar、SystemTap 等工具利器，如何将这些工具组合，并应用在适合的场景，是一门学问，相信读者会在书中找到答案。顺便说一句，Dtrace+SystemTap 帮助SAE 解决过非常多的性能疑难杂症，一定会对读者的业务分析产生帮助！

单个进程的性能分析是简单的，因为我们可以定位到system-call 或者library-call 级别，然后对照代码很快解决，但整个业务的性能分析是复杂的，这里面涉及多个业务单元、庞大的系统组件。最麻烦的是，往往造成性能问题的还不是单元本身，而是单元和单元相连接的网络服务。这就要求我们必须要有一套科学的分析方法论，来帮助我们找到整个系统业务中的瓶颈所在。书中就此介绍了包括随机变动、诊断循环等多个方法，并且介绍了涉及分析的数学建模和概念。不要忽视数学在性能分析中的作用，在实际应用中，我就利用方差和平均值的变化规律科学地分辨一套系统到底是否应该扩容。

找到了性能瓶颈，下一步就是解决问题。当然解决问题的最好办法就是改代码，但是，在你无法短时间内修改代码的时候，对系统进行优化也可以实现这一目的。这就要求我们对于系统的各个环节都要明白其工作原理和联系。本书第3章详细讨论了操作系统，这对于读者是很有用的。因为很多时候我们在不改代码的情况下优化系统，就是优化内存分配比例，就是优化CPU 亲密度，就是尝试各种调度算法，就是做操作系统层面的各种网络参数调优。

对于上述所有问题的认识，我相信读者在通读全书后会有不一样的感觉。记住，不要只读一遍，每读一遍都必有不同的体会。不多说了，我要赶紧再去读一遍:）

——丛磊 新浪SAE 创始人/总负责人