Page 251 - Web性能权威指南

XHR 轮询的性能建模

为说明如何权衡 XHR 轮询的延迟与开销，我们可以拿一个简单的邮件应用作例
子。这个应用使用 XHR 轮询检查服务器上的新邮件。实现步骤如下：
• 客户端每 60 s 发送一次 XHR 检查更新；
• 每次 XHR 请求都包含客户端知道的最近消息 ID； ਜ਼ࢽ܋ ޜခഗ ਜ਼ࢽ܋ ޜခഗ
• 服务器用客户端发送的 ID 查询其消息列表；
• 服务器响应新消息列表或空列表（表示没有更新）。

消息的平均延迟是多长时间？
如果服务器端消息恰好在客户端检查更新之前到达，那么延迟时间最短，只
有客户端到服务器的网络延迟。相反，同一条新消息如果在客户端刚刚检查
更新之后才到达，那么这条消息就要等到下次检查时才能发送（多等 60 s）。
实际上，如果消息是随机到达的，那么每条消息平均要在服务器上等待 30 s ୾კक़߰ ߸ႎ ੣ှ ߸ႎ
才能让客户端检查到。
ჽ׿
轮询的开销有多大？
HTTP 1.x 的请求与响应会增加大约 800 字节的载荷（参见 11.5 节“度量和
控制协议开销”）。加上客户端登录，还会有额外的认证 cookie 和消息 ID，假
设又会增加 50 字节。那么，返回空消息列表的请求的开销为 850 字节！假设
有 10 000 个客户端，全部以 60 s 为间隔向服务器轮询：

( 850 ጴব × 8 ࿋ × 10 000 ) ≈ 1.13 Mbit/s
60 s

算下来服务器每秒要处理 167 个请求，每个客户端每次请求要发送 850 字节数
据，相当于服务器始终要承担 1.13 Mbit/s 的入站流量！而且，这还是不向客户
端发送任何新消息情况下的一个固定速率。

30 s 的延迟是否太高了？那就缩短间隔，但这样一来，就会导致更高的吞吐量和
开销。同样还是 10 000 个客户端，如果轮询间隔缩短到 1 s，就会导致 60 Mbit/s
以上的吞吐量！简单来说，轮询间隔越短，代价越大。

15.7.2 通过XHR实现长轮询

定时轮询的一个大问题就是很可能造成大量没必要的空检查。记住这一点之后，让
我们来对这个轮询过程做一改进（图 15-1）：在没有更新的时候不再返回空响应，
而是把连接保持到有更新的时候。

238 ｜ 第 15 章