参考：《Thinking Clearly about Performance》
两个指标
响应时间：执行一个任务所耗费的时间
吞吐量：在指定的单位时间内执行任务的个数
响应时间和吞吐量“一般”是倒数关系
（真实关系比较复杂）
> 如果每秒吞吐量是1000，平均响应时间不一定是0.001秒。因为可能是有1000个并行通道，每个通道执行一个任务，响应时间是1秒。
> 如果响应时间是0.001秒，每秒吞吐量有可能100都达不到。因为请求可能来自不同的用户，请求之间不是完美连续的，可能有资源竞争等各种原因。
所以两者都得测量。
平均响应时间并不能说明一切
平均值相同的情况下：
> 如果各响应时间相差较大（方差大），可能会导致业务无法容忍那些大于平均值的时长。
> 但也有可能业务要求某些任务的响应时间极短，同时容许个别任务可以稍微花费较长时间。
问题诊断
首先确定具体期望达到的性能目标，确定这个目标是用户真实了解并期望的。
> 用序列图展示流程
> 使用专业的测量评估工具（Profiler），找出时间花在哪部分，哪部分的耗时可以接受。根据 Profiler 的结果，估算应该能达到的性能目标。
- 阿姆达尔定律
系统中对某一部件采用更快执行方式所能获得的系统性能改进程度，取决于这种执行方式被使用的频率，或所占总执行时间的比例。
- 评估每项改进所需成本。评估可能会不准确，可能会有一些关键点未考虑到，可能破坏原有设计，引发其它部分的性能问题。
- 记录改进的历史。包括期望效果，实际结果等。
- 单个子程序在不同场景性能表现分布不均匀。对某些被大量调用的子程序进行改造不一定能获得预期效果。可能单次调用耗时可以减少一半，但由于每次调用情况可能相差很大，这些调用的总体耗时并不一定能减少一半。
- 效率
* 关注业务最需要改进的地方。
* 在不牺牲业务功能的情况下，去掉冗余的操作/调用。
* 改进程序周边的环境（不合理的设计、硬件配置等）。（必要时减少系统工作量）
- 负载
（开发人员不能检测出所有性能问题的原因之一）
* Queuing Delay
各硬件（CPU、内存、磁盘等）有各自的性能拐点。
* Coherency Delay
为保持一致性引发的延迟，包括各种锁。（很难保证性能测试已验证该类延迟不会影响最终服务。）
测量方法
（吞吐量比较容易测得，准确测得响应时间比较困难。）
最好是测量真正需要的，而不是那些容易测量的替代数据。
性能只有在产品环境里才能真正体现
之前的阶段应该考虑到是否容易开展性能测试，添加收集性能相关数据的代码。