Ask HN: Why did HN just go down?
For a couple minutes, Hacker News was returning 502 Bad Gateway error codes with the message that "We're having some trouble serving your request. Sorry!".
Any idea what happened?
Any idea what happened?
I guess the twitter's way of handling huge threads is much more scalable and I think twitter's acquisition should had such a point.
Really? Why is that? It doesn't seem like that should be the case here. HN threads are only a few hundred comments, and the web page structure is very linear and formulaic (the threads do not form a tree in the DOM). I.e. it's a depth-first traversal visiting children by ranking, each comment producing a row in a table. For just a few hundred comments I would expect that to be very fast (but I don't know what data structure it's all stored in).
So if you just say like "10" comments, the letters in just one comment could be worth of 100 comments. So you also need a "show more" button for each comment exceeds some character limit.
If you do a viewport optimization, you need to calculate the rendered size of a comment section and request only comments visible for the browser viewport.
That's why it's difficult.
* Elon Mush threads shows only one thread now. https://news.ycombinator.com/item?id=31025061
Edit: Looks like it is no longer an issue. It shows latest comments.
The issue is not in DOM structure.
I'm creator of "arguman.org", maybe you've heard about it (it's down now). I had the same issues there as well.
I'm also happy with HN's plain html interface.
Also, how would you render a page with 800 nodes with user content, it is still a question. I would like to hear and learn.
Btw, yes, Bulletin board style forums is a strait forward solution, there's always some ways to do that, but there's also ways to do it like in Twitter's way. That's the point I was talking about.
It would be trivial with any site using a relational database. The two basic models used are nested sets[0], which optimize rendering over insertion and deletion, versus the much simpler relational model (rows with id and parent id, sometimes root id), which is much easier to insert and delete from, but requires recursive queries to render an entire tree from any branch other than the root. The vast majority of threaded forums use the former model, many larger sites use the latter, and rendering large threads isn't an issue either way unless maybe you're at Reddit scale, which most forums including HN aren't.
Hacker News doesn't use a relational database, it uses flat text files (limiting it to file I/O speed for data not cached in RAM), and it also runs under a single thread with limited RAM. It likely wasn't designed to operate efficiently at the scale that it currently does, and the increasing size and velocity of threads is pushing it to its limit.
Edit: looks like the stone passed.
Optimizing the render part in insertion and deletion is also difficult. Some nodes might have user-level views, so some of them won't be visible to some other users. So you can't just label the nodes like this is "left" or "right" of that record.
My experience with a similar problem: Instead of putting the rendering part to the insertion and deletion (nested set model), I was using a simple nginx file based cache. This is a trade off and I chose the application layer to be "consistent" and "reliable", over "being fast". Keeping the data integrity is difficult when you have a nested set model and it's also expensive to doing that calculation during the insertion. Sometimes you need a message broker to handle such an expensive query, because it's not safe to do it within a request-response lifecycle, even if you do have a transactional database, there's always a barrier of "request time out".
What would be slow (and may be happening), is generating that dynamically for every page refresh on a busy story by every visitor (i.e. no caching).
I'm interested to brain-storm about how to model and implement "Breaking-up" part of your comment.
For the backend part, I think Splay-tree kind of a data structure will help to serve it faster.
I think caching would be important to make it fast, and you could cache the HTML of each comment or subtree. Actually, if I was making my own forum and not copying HN I would probably have the comment tree structure represented in the DOM tree, as that seems better for navigation and accessibility. All of this is totally theoretical of course! I haven't actually done it, so may be wrong.
I agree. It's also good for screen readers, and you can also have keyboard shortcuts to navigate on tree.
It's not that hard with so few comments, it's just a matter of UX philosophy. At reddit we solved this with the "load more comments" AJAX request and "continue this thread". "Continue" only happens when a tree gets too deep, and then is just sets the current comment as the top of the tree and recalculates.
"load more" happens after the comment limit was reached, but since it's AJAX it doesn't really take away from the viewing experience (and I think in new reddit it just auto loads when you scroll to it).
Here's the reddit code if you want to see it: https://github.com/reddit-archive/reddit/blob/master/r2/r2/l...
The main issue for HN is that it's static so when a node gets a lot of children, it breaks a lot of their assumptions and makes for very large blobs of HTML to display the tree.
Honestly it's probably a worthwhile tradeoff -- for the most part the threads here don't get so deep that it's a problem, and in exchange we get a super snappy website most of the time.
In any event, don't worry about it! There are other sites on the internet.
Any suggestions? Sometimes I peek back at Slashdot. Otherwise Hacker News is my goto aggregator.