摘要：性能优化通常是在现有系统和代码基础上做改进，考验的是开发者反向修复的能力，而性能设计考验的是设计者的正向设计能力，但性能优化的方法可以指导性能设计，两者互补。
性能优化是指在不影响正确性的前提下，使程序运行得更快，它是一个非常广泛的话题。
优化有时候是为了降低成本，但有时候，性能能决定一个产品的成败，比如游戏服务器的团战玩法需要单服达到一定的同时在线人数才能支撑起这类玩法，而电信软件的性能往往是竞标的核心竞争力，性能关乎商业成败。
软件产品多种多样，影响程序执行效率的因素很多，因此，性能优化，特别是对不熟悉的项目做优化，不是一件容易的事。
性能优化可分为宏观和微观两个层面。宏观层面包括架构重构，而微观层面，则包括算法的优化，编译优化，工具分析，高性能编码等，这些方法是有可能独立于具体业务逻辑，因而有更加广泛的适应性，且更易于实施。
具体到性能优化的方法论，首先，应建立度量，你度量什么，你得到什么。所以，性能优化测试先行，须基于数据而不能凭空猜测，这是做优化的一个基本原则。搭建真实的压测环境，或者逼近真实环境，有时候是困难的，也可能非常耗费时间，但它依然是值得的。
有许多工具能帮助我们定位程序瓶颈，有些工具能做很友好的图形化展示，定位问题是解决问题的前置条件，但定位问题可能不是最难的，分析和优化才是最耗时的关键环节，修改之后，要再回归测试，验证是否如预期般有效。
什么是高性能程序？架构致广远、实现尽精微。
架构优化的关键是识别瓶颈，这类优化有很多套路：比如通过负载均衡做分布式改造，比如用多线程协程做并行化改造，比如用消息队列做异步化和解耦，比如用事件通知替代轮询，比如为数据访问增加缓存，比如用批处理+预取提升吞吐，比如IO与逻辑分离、读写分离等等。
架构调整和优化虽然收效很大，却因受限于各种现实因素，因而并不总是可行。
能不做的尽量不做、必须做的高效做是性能优化的一个根本法则，提升处理能力和降低计算量可视为性能优化的两个方向。
有时候，我们不得不从细节的维度去改进程序。通常，我们应该使用简单的数据结构和算法，但如有必要，就应积极使用更高效的结构和算法，不止逻辑结构，实现结构（存储）同样影响执行效率；分支预测、反馈优化、启发性以及基于机器学习编译优化的效果日益凸显；熟练掌握编程语言深刻理解标准库实现能帮助我们规避低性能陷阱；深入细节做代码微调甚至指令级优化有时候也能取得意想不到的效果。
有时候，我们需要做一些交换，比如用空间置换时间，比如牺牲一些通用性可读性换取高性能，我们只应当在非常必要的情况下才这么做，它是权衡的艺术。
1、架构优化通常系统的throughput越大，latency就越高，但过高的latency不可接受，所以架构优化不是一味追求throughput，也需要关注latency，追求可接受latency下的高throughput。
负载均衡负载均衡其实就是解决一个分活的问题，对应到分布式系统，一般在逻辑服的前面都会安放一个负载均衡器，比如NGINX就是经典的解决方案。负载均衡不限于分布式系统，对于多线程架构的服务器内部，也需要解决负载均衡的问题，让各个worker线程的负载均衡。
多线程、协程并行化虽然硬件架构的复杂化对程序开发提出了更高的要求，但编写充分利用多CPU多核特性的程序能获得令人惊叹的收益，所以，在同样硬件规格下，基于多线程/协程的并行化改造依然值得尝试。
多线程不可避免要面临资源竞争的问题，我们的设计目标应该是充分利用硬件多执行核心的优势，减少等待，让多个执行流畅快的奔跑起来。
对于多线程模型，如果把每一个要干的活抽象为一个task，把干活的线程抽象为worker，那么，有两种典型的设计思路，一种是对task类型做出划分，让一类或者一个worker去干特定的task，另一种是让所有worker去干所有task。