6 ms·

This is only slightly related, but I've noticed HN comment pages take a second or two to load when there are many comments (500+). Page sizes are not unreasonab

This is only slightly related, but I've noticed HN comment pages take a second or two to load when there are many comments (500+). Page sizes are not unreasonable (100-200 kb). What is the cause for these pages loading so slowly? Example 900+ comment page: https://news.ycombinator.com/item?id=11116274 https://news.ycombinator.com/item?id=11116274 Example 2200+ comment page: https://news.ycombinator.com/item?id=12907201 https://news.ycombinator.com/item?id=12907201

deleted 10y ago
[deleted]
yellowbeard 10y ago
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.

deleted 10y ago

[deleted]

yellowbeard 10y ago

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.