在更快 FastCGI一文中，我讨论了在 /dev/shm 中使用临时文件来减少大型 FastCGI 请求的开销。Robert 立即实现了它，并且它已在最新的预发布版本中可用。

很早就醒来，喝着第一杯咖啡时，我分享了一些关于如何利用这一点来加速基于 AJAX 的应用程序的想法。

大响应内容

Robert 已经做了一些基准测试，看起来如果你需要发送超过 16KB 的内容，X-LIGHTTPD-send-temp-file 会有所帮助。否则，它会适合一个 FastCGI 数据包和 TCP 接收缓冲区。无聊，对吧？让我们再进一步，将这个想法向前推进一些。

预生成内容

在六月份的 railsconf 会议上，Zed Shaw 和我讨论了一些加速 Rails 应用，特别是那些时髦的 Web 2.0 应用的方法。

通常，组件之间存在依赖关系。假设你正在编写一个邮件应用，并且你正在轮询“收到新邮件”服务，并希望通过淡入效果显示它，同时刷新文件夹列表以显示新的邮件计数。

我们希望表现良好，只加载真正已更改的组件，因此你有 1 到 3 个 XMLHTTP 请求

1. “你收到邮件了”淡入效果
2. 如果有新邮件，则文件夹列表会更新
3. 如果新邮件在当前文件夹中，文件夹视图也会更新

在 AJAX 世界中，你有更小的请求，但所有请求在生成内容之前都必须先加载会话。如果你反其道而行，将上述逻辑移回服务器，“你收到邮件了”只加载一次会话，并为所有 3 个部分生成内容，因为它知道应用程序无论如何都会在接下来的 1-2 秒内请求这些内容，那会怎么样？

这将使文件夹列表和文件夹视图的请求变得即时，因为它们只需检查内容文件是否存在，并可以立即使用 X-LIGHTTPD-send-temp-file 将其流式传输出去。

现在你只需要在 mtime 上加入一些清理机制，以防临时文件未被获取[也许是 memcached？]，还必须找到一种无需先读取会话即可猜测文件名的方法[这是我们想摆脱的开销大的部分]，……

预读

从某种意义上说，这就像硬盘的预读，或者 CPU 的预取，甚至像浏览器的链接预取。

这个主意怎么样？

那么，你觉得这个想法怎么样？你有什么可以通过这种方式解决的问题吗？