9 月 22 日上午，torun.ai 慢得几乎走不动。一批自动化浏览器，在四十五分钟里来自两千多个地址，逐个请求我们的公开页面，最糟糕的那一分钟大约是每秒三页。一个网站本该对此毫无感觉。我们的却扛不住：最繁忙的时段里，超过四分之一的请求耗时超过三十秒，数百名访客没等页面出来就离开了。
不是我们以为的负载
最明显的嫌疑是爬虫和处理器，但两者都站不住脚。我们在网站副本上重放同样的每秒三页，它撑了不到一分钟，之后就什么请求都完成不了了。处理器占用从 60% 降到 1%，线程数却从 12 涨到 166。过载的服务器会更忙；这台却在等待。
每个词都要往返一次
在单个页面生成期间观察缓存服务器，就看清了它在等什么。一个页面向它发送了 585 条命令，其中 428 条是同一个查询及其续期，反复出现：一张对我们网站来说是空的翻译表。页面上每一段翻译文字，而一个页面有好几百段，都要重新请求它一次，每次请求都会占住一个线程，直到结果返回。每秒三页时线程就耗尽了，所有请求都排在它们后面。
修复，以及一道限流
这些查询现在每次从内存中返回一分钟，过期时只重新获取一次，并在修改翻译的那台服务器上清除。同一个页面现在只发送 31 条命令，而不是 585 条。我们还在页面生成前加了一道限流：同时只生成固定数量的页面，一个短队列等待，超出部分会立刻收到“请稍后再试”，而不是拖慢所有页面。
在生产环境实测
9 月 23 日发布之后，我们重新测量了线上网站。页面生成的中位时间是 42 毫秒，之前是 249 毫秒；每二十个里最慢的是 72 毫秒，之前将近两秒。每个页面原本要执行 214 次的查询，现在只执行一次。
我们记下的教训很简单：容量数字是测出来的，不是信出来的。我们从没测过公开网站能承受多少。现在测过了，以后给出数字之前还会再测。