需求分析对性能优化有什么帮助呢，第一，为了达到同样的目的，解决同样问题，也许可以有性能更优（消耗更小）的办法。这种优化是无损的，即不改变需求本质的同时，又能达到性能优化的效果；第二种情况，有损的优化，即在不明显影响用户的体验，稍微修改需求、放宽条件，就能大大解决性能问题。PM退步一小步，程序前进一大步。
需求讨论也有助于设计时更具扩展性，应对未来的需求变化，这里按下不表。
设计阶段高手都是花80%时间思考，20%时间实现；新手写起代码来很快，但后面是无穷无尽的修bug
设计的概念很宽泛，包括架构设计、技术选型、接口设计等等。架构设计约束了系统的扩展、技术选型决定了代码实现。编程语言、框架都是工具，不同的系统、业务需要选择适当的工具集。如果设计的时候做的不够好，那么后面就很难优化，甚至需要推到重来。
实现阶段实现是把功能翻译成代码的过程，这个层面的优化，主要是针对一个调用流程，一个函数，一段代码的优化。各种profile工具也主要是在这个阶段生效。除了静态的代码的优化，还有编译时优化，运行时优化。后二者要求就很高了，程序员可控性较弱。
代码层面，造成性能瓶颈的原因通常是高频调用的函数、或者单次消耗非常高的函数、或者二者的结合。
下面介绍针对设计阶段与实现阶段的优化手段。
1、一般性方法 缓存没有什么性能问题是缓存解决不了的，如果有，那就再加一级缓存
a cache /kæʃ/ KASH,[1] is a hardware or software component that stores data so future requests for that data can be served faster; the data stored in a cache might be the result of an earlier computation, or the duplicate of data stored elsewhere.
缓存的本质是加速访问，访问的数据要么是其他数据的副本 -- 让数据离用户更近；要么是之前的计算结果 -- 避免重复计算.
缓存需要用空间换时间，在缓存空间有限的情况下，需要优秀的置换换算来保证缓存有较高的命中率。
数据的缓存这是我们最常见的缓存形式，将数据缓存在离使用者更近的地方。比如操作系统中的CPU cache、disk cache。对于一个web应用，前端会有浏览器缓存，有CDN，有反向代理提供的静态内容缓存；后端则有本地缓存、分布式缓存。
数据的缓存，很多时候是设计层面的考虑。
对于数据缓存，需要考虑的是缓存一致性问题。对于分布式系统中有强一致性要求的场景，可行的解决办法有lease，版本号。
计算结果的缓存对于消耗较大的计算，可以将计算结果缓存起来，下次直接使用。
我们知道，对递归代码的一个有效优化手段就是缓存中间结果，lookup table，避免了重复计算。python中的method cache就是这种思想.
对于可能重复创建、销毁，且创建销毁代价很大的对象，比如进程、线程，也可以缓存，对应的缓存形式如单例、资源池（连接池、线程池）。
对于计算结果的缓存，也需要考虑缓存失效的情况，对于pure function，固定的输入有固定的输出，缓存是不会失效的。但如果计算受到中间状态、环境变量的影响，那么缓存的结果就可能失效，比如我在前面提到的[python method cache][]
并发一个人干不完的活，那就找两个人干。并发既增加了系统的吞吐，又减少了用户的平均等待时间。
这里的并发是指广义的并发，粒度包括多机器（集群）、多进程、多线程。
对于无状态（状态是指需要维护的上下文环境，用户请求依赖于这些上下文环境）的服务，采用集群就能很好的伸缩，增加系统的吞吐，比如挂载nginx之后的web server
对于有状态的服务，也有两种形式，每个节点提供同样的数据，如mysql的读写分离；每个节点只提供部分数据，如mongodb中的sharding
分布式存储系统中，partition（sharding）和replication（backup）都有助于并发。
绝大多数web server，要么使用多进程，要么使用多线程来处理用户的请求，以充分利用多核CPU，再有IO阻塞的地方，也是适合使用多线程的。比较新的协程（Python greenle、goroutine）也是一种并发。
惰性将计算推迟到必需的时刻，这样很可能避免了多余的计算，甚至根本不用计算，这个在之前的《[lazy ideas in programming][]》一文中举了许多例子。
CopyOnWrite这个思想真牛逼！
批量，合并在有IO（网络IO，磁盘IO）的时候，合并操作、批量操作往往能提升吞吐，提高性能。