[icebraining]

Slashdot's solution to this was to render the HTML on write, instead of on read. Whenever someone posted a new commend, a static HTML file would get generated, so that it could be rapidly served to readers. Movable Type works (can work?) much in the same way, though for blogs.

I know that caching achieves a similar result and is an accepted component of a modern architecture, but I wonder if we wouldn't be better served by implementing these sort of "upfront caches" in more software.

[manarth]

  Whenever someone posted a new commend, a static HTML file would get generated

It's essentially still a cache, with the same concerns/issues - mainly cache invalidation - as a HTTP cache.

An on-disk cache of that sort has other issues though. For example, what if a request is received whilst the file is being written? Does the system deliver a half-written HTML page? You can introduce locking or atomic file operations (write to a temporary directory, then mv the file into the correct location: mv is an atomic operation), but this adds more complexity to the cache logic.

One of the benefits of a HTTP cache is that they generally have a default graceful failure mode: if the cached data doesn't exist, request it from the backend application server.

[icebraining]

The issue doesn't seem any different - assuming you have concurrent requests, you also have to make sure the cache doesn't return a result until the whole document is written to it.

[manarth]

That's a fair point - I didn't consider that issue, because using a standard HTTP cache, that's taken care of.

It's just become somebody else's problem (the developers of the HTTP cache), but it's fair to say it's still an issue to solve.