性能的一些基本概念和原则

参考： 《Thinking Clearly about Performance》

两个指标

响应时间：执行一个任务所耗费的时间

吞吐量：在指定的单位时间内执行任务的个数

响应时间和吞吐量“一般”是倒数关系

（真实关系比较复杂）

> 如果每秒吞吐量是1000，平均响应时间不一定是0.001秒。因为可能是有1000个并行通道，每个通道执行一个任务，响应时间是1秒。

> 如果响应时间是0.001秒，每秒吞吐量有可能100都达不到。因为请求可能来自不同的用户，请求之间不是完美连续的，可能有资源竞争等各种原因。

所以 两者都得测量。

平均响应时间并不能说明一切

平均值相同的情况下：

> 如果各响应时间相差较大（方差大），可能会导致业务无法容忍那些大于平均值的时长。

> 但也有可能业务要求某些任务的响应时间极短，同时容许个别任务可以稍微花费较长时间。

问题诊断

首先确定具体期望达到的性能目标，确定这个目标是用户真实了解并期望的。

> 用序列图展示流程

> 使用专业的测量评估工具（Profiler），找出时间花在哪部分，哪部分的耗时可以接受。根据 Profiler 的结果，估算应该能达到的性能目标。

- 阿姆达尔定律

系统中对某一部件采用更快执行方式所能获得的系统性能改进程度，取决于这种执行方式被使用的频率，或所占总执行时间的比例。

- 评估每项改进所需成本。评估可能会不准确，可能会有一些关键点未考虑到，可能破坏原有设计，引发其它部分的性能问题。

- 记录改进的历史。包括期望效果，实际结果等。

- 单个子程序在不同场景性能表现分布不均匀。对某些被大量调用的子程序进行改造不一定能获得预期效果。可能单次调用耗时可以减少一半，但由于每次调用情况可能相差很大，这些调用的总体耗时并不一定能减少一半。

- 效率

* 关注业务最需要改进的地方。

* 在不牺牲业务功能的情况下，去掉冗余的操作/调用。

* 改进程序周边的环境（不合理的设计、硬件配置等）。（必要时减少系统工作量）

- 负载

（开发人员不能检测出所有性能问题的原因之一）

* Queuing Delay

各硬件（CPU、内存、磁盘等）有各自的性能拐点。

* Coherency Delay

为保持一致性引发的延迟，包括各种锁。（很难保证性能测试已验证该类延迟不会影响最终服务。）

测量方法

（吞吐量比较容易测得，准确测得响应时间比较困难。）

最好是测量真正需要的，而不是那些容易测量的替代数据。

性能只有在产品环境里才能真正体现

之前的阶段应该考虑到是否容易开展性能测试，添加收集性能相关数据的代码。