3 ms·

The server is taking a long time to render the response. In the first link, 650ms or so. Open the network tab in your browser developer tools to see the details

The server is taking a long time to render the response. In the first link, 650ms or so. Open the network tab in your browser developer tools to see the details.

icebraining 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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.

The server is taking a long time to render the response. In the first link, 650ms or so. Open the network tab in your browser developer tools to see the details.

icebraining 10y ago

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 10y ago
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 10y ago
  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 10y ago
    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.