前言
我们先来看一家工厂的装配流水线。工人在流水线将现成的组件按顺序拼接,组装成自行车。通过实地观测, 我们发现从组件进入生产线，到另一端组装成自行车需要4小时。
继续观察，我们还发现，此后每分钟就有1辆自行车完成组装,，每天24小时，一直如此。将这个模型简化, 并忽略维护窗口期后得出结论： 这条流水线每小时可以组装60辆自行车。
通过这两种测量方法，就知道了生产线的相关性能信息： 延迟与吞吐量:
生产线的延迟: 4小时
生产线的吞吐量: 60辆/小时
注意：衡量延迟的时间单位根据具体需要而确定 —— 从纳秒(nanosecond)到几千年(millennia)都有可能。系统的吞吐量是每个单位时间内完成的操作。操作(Operations)一般是特定系统相关的东西。在本例中,选择的时间单位是小时, 操作就是对自行车的组装。
掌握了延迟和吞吐量两个概念之后, 让我们对这个工厂来进行实际的调优。自行车的需求在一段时间内都很稳定, 生产线组装自行车有四个小时延迟, 而吞吐量在几个月以来都很稳定: 60辆/小时。假设某个销售团队突然业绩暴涨, 对自行车的需求增加了1倍。客户每天需要的自行车不再是 60 * 24 = 1440辆, 而是 2*1440 = 2880辆/天。老板对工厂的产能不满意，想要做些调整以提升产能。
看起来总经理很容易得出正确的判断，系统的延迟没法子进行处理 —— 他关注的是每天的自行车生产总量。得出这个结论以后, 假若工厂资金充足, 那么应该立即采取措施, 改善吞吐量以增加产能。
我们很快会看到，这家工厂有两条相同的生产线。每条生产线一分钟可以组装一辆成品自行车。 可以想象，每天生产的自行车数量会增加一倍。达到 2880辆/天。要注意的是，不需要减少自行车的装配时间 —— 从开始到结束依然需要 4 小时。
在这里做了一个很重要的决定 —— 要增加吞吐量，而不是减小延迟。在增加吞吐量的同时，也需要增加系统容量。比起原来的情况，现在需要两条流水线来生产出所需的自行车。在这种情况下，增加系统的吞吐量并不是免费的，需要水平扩展，以满足增加的吞吐量需求。
在处理性能问题时，应该考虑到还有另一种看似不相关的解决办法。假如生产线的延迟从1分钟降低为30，那么吞吐量同样可以增长 1 倍。
或者是降低延迟，或者是客户非常有钱。软件工程里有一种相似的说法 —— 每个性能问题背后,总有两种不同的解决办法。 可以用更多的机器，或者是花精力来改善性能低下的代码。
延迟
延迟指标通常如下所述：
所有交易必须在10秒内得到响应
90%的订单付款操作必须在3秒以内处理完成
推荐商品必须在 100 ms 内展示到用户面前。
Throughput(吞吐量)
吞吐量指标通常如下所述：
解决方案每天必须处理 100万个订单
解决方案必须支持1000个登录用户,同时在5-10秒内执行某个操作: A、B或C
每周对所有客户进行统计, 时间不能超过6小时，时间窗口为每周日晚12点到次日6点之间。