在最基本的系统中，有一个中央调度器，负责告知每部电梯需要停靠哪些楼层。每当新的指令发出时，系统会将其分配给最近的电梯。不过，正如我们即将看到的，我们可以做得更好。
我们该如何实际评估电梯调度算法的优劣？最直观的指标是你等待电梯到达所需的时间。
一个简单的衡量标准是：“电梯在30秒内到达的频率是多少？”或者“电梯在90秒内到达的频率是多少？”
更严谨地说，我们需要观察等待时间的分布。如果将数千次乘坐的等待时间绘制成图，我们会得到如下所示的直方图。
p90为2分钟意味着90%的情况下，乘客等待电梯的时间不超过2分钟。p50为1分钟意味着一半情况下电梯在1分钟内即可到达。
人们通常不会记住自己平均等待了多久，而会牢牢记住那些电梯似乎“永远”不来的情况——也就是p90对应的极端案例。
并非所有客流模式都是相同的。想象一栋大型企业办公楼：早晨，几乎所有客流都集中于从大厅前往上层楼层。
傍晚时分，情况完全反转，所有人都在离开大楼。午餐高峰则混合了两种方向，而其余时段则多是楼层间的流动。
等待时间的分布因时间段和电梯面临的客流模式而有显著差异。早高峰的等待时间历来是最糟糕的。
在分析LOOK电梯算法时，我们仔细考察（双关：look）了乘客是如何被分配到轿厢的。我们最初天真地将每个指令分配给最近的轿厢，但提到我们能够做得更好。
如果最近的轿厢已经满员怎么办？我们可以运用Otis的RSR（相对系统响应）算法来优化。RSR会为每部轿厢评分，评估其接送乘客的适配度，得分越低表示越适合。
RSR每5秒还会重新优化一次。原本由电梯A接送的乘客，如果电梯A遇到延误，可以重新分配给电梯B。这种动态优化对于疏通客流至关重要。
在下面的图示中，每部电梯亮起时，代表它恰好是响应3楼呼叫按钮的最佳选择。随着电梯移动，最佳选择不断变化，展示了优化器的实时运作。
借助我们的电梯分析工具箱，我们可以对LOOK算法与RSR算法进行性能基准测试，以了解更智能的算法究竟能将等待时间改善多少。
有趣的是，随着客流量增大，LOOK算法实际上开始超越RSR。当电梯总是满员且每层都停靠时，额外的规则就不再那么重要了。
LOOK算法在每组电梯数量较少的小型建筑中也往往优于RSR。有时化繁为简才是更佳选择。
你还可以追踪另一个指标：行程时间，即乘客在电梯内实际等待到达目标楼层的时长。RSR和LOOK算法在这方面也存在差异，但这已超出本文讨论范