本文为<< Performance Tuning: A Comprehensive Guide >>读书笔记. 另请参阅:
做过性能调优的同学都知道, 最怕的不是性能差, 而是费了半天劲在细节上死抠, 却忽视了另外一整个对性能有巨大影响的维度, 旁边放着一西瓜却使劲在芝麻上雕花. 针对这种情况, << Performance Tuning: A Comprehensive Guide >>的作者梳理了影响性能的几个维度, 具备一定的完整性, 新手可以按图索骥的去调优, 老手也可以拿来参考看看是否漏掉了某些事半功倍的方法.
这里谈到的性能是一种统称, 包含响应时间/延迟latency, 吞吐量throughput等, 也暂时不涉及压力测试负载测试等手段类似但意图不同的测试(它们之间的联系和区别可参考 Restatement: 性能,容量,负载,以及压力测试 )
该体系将影响性能的因素分了三大类, 分别是
这三类基本囊括了所有因素. 下面我们来看一下里面的细节.
这通常是我们一头扎进去就开始局部优化的地方. 常用的手段包括使用各种 Profiler 来度量 CPU 时间, 内存占用率, 函数调用次数以进行问题定位, 然后实施各种调优方法, 比如优化循环, 空间换时间等.
选择合适的数据结构自然算作此类优化, 而我们把不同存储模型等较大规模的优化也归为此类, 比如使用 Document 代替关系型存储等.
这个方向的优化可以很快的帮助我们消除一些明显的编程细节引起的瓶颈, 但过了初期突飞猛进的阶段后, 每获得一点改善, 都需要付出巨大的智力上的努力, 事半功倍. 不要忘了我们还有另外的武器.
运行环境与资源包括各种软硬件平台: 操作系统, 数据库, 运行平台, CPU, 内存, 磁盘, 网络等等. 最简单, 最省事的调优方法其实是优化硬件资源, 使用快速计算资源代替慢速计算资源, 提升资源计算能力:
而运行平台的软件部分, 比如操作系统, 数据库, 中间件等, 调优的成本要高一些, 并且有可能工作量大到不可接受. 比如从 Windows 平台迁移到 Linux 平台, 从数据库 A 切换到数据库 B, 从 EJB 切换到 Spring… 这些最好在初期就考虑好
这类调优见效快, 但受制于预算, 及硬件本身的限制. 通常很快这类调优会在榨取最后一点计算资源后, 遇到瓶颈.
而我们通常谈论的焦点, 也是当前各种调优实践最集中的领域, 是优化算法和资源间的交互, 包括:
调优一般发生在单台机器处理能力已达上限的情况. 一个思路就是把压力分散到多台机器上, 从而使每台机器都能获得可接受的延迟或吞吐量.
总的原则是分而治之. 分的维度包括业务, 组件边界, 访问频率或对系统资源的消耗程度, 瓶颈资源等
一旦按上述维度分好了, 还可以在所有维度上应用 负载均衡 , 把访问量分散到不同服务器.
可以看出缓存是减少不必要计算和 IO 的重要手段. 缓存的设计主要是根据资源变化频率对资源进行分类, 比如动静分离等. 其前提是恰当的状态管理, 分离无状态的逻辑和有状态的逻辑, 并付出一定的对一致性的妥协, 运维的复杂为代价.
缓存的适用场景:
以上所有手段可以组合使用, 有冲突时再做权衡.
另请参阅: