1. 什么是 SMMU？

outline：关注 &指标 &度量，基础理论知识，工具 &方法，最佳实践，参考资料

性能优化关注：CPU、内存、磁盘 IO、网络 IO 等四个方面。

性能指标：吞吐率、响应时间、QPS/IOPS、TP99、资源使用率是我们经常关注的指标。

时间度量：从 cpu cycle 到网络 IO，自上到下，时间量级越大。

监控、分析、优化，三部曲，以终为始，循环往复。

优化性能，需要一些系统编程知识。

提升处理能力、减少计算量是优化的 2 个根本方向。

优化大师格雷格画的图，吊炸天，你应该很熟悉，gregg 亲手实现了一些工具。

借助工具定位性能瓶颈。gprof2dot.py 可以处理多种采样输出数据

建议使用 perf 等非侵入式的 profiling 工具。

perf 不仅仅可以定位 cpu 瓶颈，还可以查看很多方面，比如缺页，分支预测失败，上下文切换等。

IO 瓶颈，你应该知道的知识。

有关锁的知识，你应该知道的。

多线程的学问很大

内存管理的方方面面

最佳实践，没有足够理由，你不应该违背。

你应该懂得的。

关于排序，你应该知道的。

这些资料不错，你值得拥有。

如果对你有帮助，请帮忙转发，让更多朋友收益。

• 一般性原则

• 依据数据而不是凭空猜测

• 忌过早优化

• 忌过度优化

• 深入理解业务

• 性能优化是持久战

• 选择合适的衡量指标、测试用例、测试环境

• 性能优化的层次

• 需求阶段

• 设计阶段

• 实现阶段

• 一般性方法

• 缓存

• 并发

• 惰性

• 批量，合并

• 更高效的实现

• 缩小解空间

• 性能优化与代码质量

• 总结

依据数据而不是凭空猜测

这是性能优化的第一原则，当我们怀疑性能有问题的时候，应该通过测试、日志、profillig 来分析出哪里有问题，有的放矢，而不是凭感觉、撞运气。一个系统有了性能问题，瓶颈有可能是 CPU，有可能是内存，有可能是 IO（磁盘 IO，网络 IO），大方向的定位可以使用 top 以及 stat 系列来定位（vmstat，iostat，netstat...），针对单个进程，可以使用 pidstat 来分析。

在本文中，主要讨论的是 CPU 相关的性能问题。按照 80/20 定律，绝大多数的时间都耗费在少量的代码片段里面，找出这些代码唯一可靠的办法就是 profile，我所知的编程语言，都有相关的 profile 工具，熟练使用这些 profile 工具是性能优化的第一步。

忌过早优化

The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.

我并不十分清楚 Donald Knuth 说出这句名言的上下文环境，但我自己是十分认同这个观念的。在我的工作环境（以及典型的互联网应用开发）与编程模式下，追求的是快速的迭代与试错，过早的优化往往是无用功。而且，过早的优化很容易拍脑袋，优化的点往往不是真正的性能瓶颈。

忌过度优化

As performance is part of the specification of a program – a program that is unusably slow is not fit for purpose

性能优化的目标是追求合适的性价比。

在不同的阶段，我们对系统的性能会有一定的要求，比如吞吐量要达到多少多少。如果达不到这个指标，就需要去优化。如果能满足预期，那么就无需花费时间精力去优化，比如只有几十个人使用的内部系统，就不用按照十万在线的目标去优化。

而且，后面也会提到，一些优化方法是“有损”的，可能会对代码的可读性、可维护性有副作用。这个时候，就更不能过度优化。

深入理解业务

代码是服务于业务的，也许是服务于最终用户，也许是服务于其他程序员。不了解业务，很难理解系统的流程，很难找出系统设计的不足之处。后面还会提及对业务理解的重要性。

性能优化是持久战

当核心业务方向明确之后，就应该开始关注性能问题，当项目上线之后，更应该持续的进行性能检测与优化。

现在的互联网产品，不再是一锤子买卖，在上线之后还需要持续的开发，用户的涌入也会带来性能问题。因此需要自动化的检测性能问题，保持稳定的测试环境，持续的发现并解决性能问题，而不是被动地等到用户的投诉。

选择合适的衡量指标、测试用例、测试环境

正因为性能优化是一个长期的行为，所以需要固定衡量指标、测试用例、测试环境，这样才能客观反映性能的实际情况，也能展现出优化的效果。

衡量性能有很多指标，比如系统响应时间、系统吞吐量、系统并发量。不同的系统核心指标是不一样的，首先要明确本系统的核心性能诉求，固定测试用例；其次也要兼顾其他指标，不能顾此失彼。

测试环境也很重要，有一次突然发现我们的 QPS 高了许多，但是程序压根儿没优化，查了半天，才发现是换了一个更牛逼的物理机做测试服务器。