看到一个操作变慢时，最容易做的是立刻寻找可以优化的代码。但没有尺度的优化无法说明改善了什么，也无法判断代价是否值得。
先定义用户感受到的变化
单次请求的平均耗时可能没有变化，尾部延迟却已经影响了少数重要操作。先确认用户真正感受到的是等待、失败，还是资源消耗，才能选择合适的指标。
让比较保持可重复
记录环境、输入范围和测量方法。一次漂亮的数字并不能代表趋势，只有在相近条件下重复观察，结果才足以支持下一次决定。
优化的起点不是更快，而是知道什么需要变快，以及快了之后如何被确认。
在优化之前先找到尺度
性能讨论需要一个可以复核的尺度，否则优化很容易变成偏好的竞争。