6 ms·
There is something comical about this: HN receives an absurd amount of traffic. More than startups and corporations with millions of customers and millions if n
by axegon_ 5y ago
There is something comical about this: HN receives an absurd amount of traffic. More than startups and corporations with millions of customers and millions if not billions of dollars behind them, and yet it runs on effectively an arduino nano compared to what they are using. HN serves all the contents significantly faster than any of them at the fraction of the time and cost. Let's take my old job for instance: the company website had almost nothing on it: a list of products, a jobs page and that's it. That website ran on 12(yes, twelve) dell servers, each having a 4 socket motherboard, each occupied by a 12 core xeon, and each of those servers had 384 gigs of ram. Sure, it tracked every click and whatnot but the data that was tracked was never actually used and the all-beloved bundle.min.js was 15 megabytes. So much for low carbon footprint and all that...
- brimble 5y agoIt also fails gracefully. Logged-in users may find the site unusable while it still loads for logged-out readers just fine (from cache).
- sulam 5y ago6M requests a day. Assuming a "US East Coast dominates" traffic pattern which is typical for this kind of site, that means their rps probably spikes north of 10K, but I'd be surprised if it's over 50K. I disagree that startups with millions of customers handle less traffic. There are probably some exceptions that prove the rule, but once you're into millions of customers you are most likely over 50K rps at peak times.
- zozbot234 5y agoMost startups with "millions of customers" can also trivially shard their traffic so it can effectively run on a bunch of largely-independent boxes, with some added redundancy for reliability's sake. No need for anything more complex.
- sulam 5y agoLet's say "trivially shard most of their traffic" and I can agree. Product managers are constantly coming with cool ideas that are hard to shard.
- ericpauley 5y ago10k rps would be 36M requests in an hour, so the peak is likely far lower than that, probably closer to 1k/s.
- sulam 5y agoMath on peak RPS doesn't work that way. It's extremely non-uniform. I agree that 10K rps wouldn't be sustained for an hour, but I bet they hit it at points, or get close to it. 1k rps is likely something they exceed for 10's of minutes every day. At any rate they should be able to serve that easily off one box, so the architecture holds up.
- ericpauley 5y ago6M per day is an average of 70rps. It would be highly unusual to have a 100x variation from the mean on such a large traffic volume. Let's imagine that all the traffic occurs in a single hour (6M per hour) and is Poisson distributed. Even then to reach 10,000 rps would require a second with 6x the average traffic volume for that hour. Admittedly this could theoretically occur when some correlated event causes everyone to browse HN, but historically the site goes down during those. For comparison our service (also largely US-centric) served 30M views yesterday with a peak volume of ~1000rps.
- sulam 5y agoI'm going to assume that since you are referring to exponential distributions in one part of your response that you're familiar with this topic, even though you refer to averages in another part. Averages are, as you likely know, completely irrelevant when it comes to predicting peak load. Yes, 10K is likely an overestimate by some factor, however it's in the realm of possible. We can argue how much of an overestimate, but I don't think this takes away from the main point that I was trying to make above, which is that they are very unlikely to exceed the serving capacity of a single host (I don't know how fast Arc is, but a well-tuned serving system should be able to handle 40K rps for simple to cache content, which HN surely qualifies as).
- bin_bash 5y ago> absurd amount of traffic Not sure what platforms you've worked on but "6M requests/day" is peanuts in my neighborhood. (No offense to dang and team which do a fantastic job, but that's not high throughput compared to almost any platform I've worked on over the past decade.)
- deleted 5y ago[deleted]
- nkozyra 5y agoThat's definitely less than I'd expected and now it doesn't feel all that magical that it's running from a single box. I have a site with ~ 2.5M req/day running on an m3.medium instance that rarely spikes 10% cpu. NGINX is frontline server probably handling a good % of those request directly before passing others via proxy.
- peter422 5y agoAlso you have to imagine the bulk of the traffic is going to be the same small bits of data (the homepage, top stories comment pages, etc). It’s not trivial to take advantage of that but that is also much easier to handle than QPS that are distributed across your dataset (IE Facebook or Twitter where everybody is seeing different things).
- zbuf 5y agoBut that's all part of the overall achievement -- 6M requests/day is a key part of the optimisation, and how much real world "traffic" that corresponds too.
- axegon_ 5y agoMuch much larger, albeit distributed across multiple datacenters and completely isolated environments. The site I was giving as an example was going possibly serving around 10-20M/day, and it isn't an isolated case: I know plenty of companies that allocate such resources for something like that.
- chubot 5y ago
- mschuster91 5y agoOn the other side, it is not much content to begin with. Traffic is a bit of text, extremely basic CSS, no images, no tracking, no bullshit means that load times are probably instantaneous even on a 56k modem. Content is a bit of plain text => easy rendering, the entire database probably would fit into memory, so not much in terms of i/o going on.
- bin_bash 5y agoIt's also gotta be super read heavy so traditional caching methods would work well
- mschuster91 5y agoOnly on the database side, and most people will be logged in, making rendering caches obsolete. What I have utterly no idea is how the karma system works. Updating karma counts and comment sorting only on new submissions would help with performance, but on the other side karma "decays" over time, so there needs to be some sort of external cron?
- fouc 5y agoI would expect fragment caching to exist.
- asadlionpk 5y agomaybe the decay is coded in render logic for homepage with (now()-postedTime) kind of logic.
- deleted 5y ago[deleted]
- deckard1 5y agoyou could probably use a weight system. Yesterday's upvote is worth a value of 1. Today's upvote is a value of 2, etc. Then store the absolute count in another column/field if you need that.
- 5y ago
- tannhaeuser 5y agoYet the audience brags about absurd complexity in the name of scalability, availability, metrics, etc. generation after generation.
- 0xdeadbeefbabe 5y agoMark Twain would make fun of us, but luckily he's not around.
- SkyPuncher 5y agoHN is a niche internet community. Niche internet communities have almost always existed despite the "quality" of the tools they run on. It's not really fair to compare to any sort of consumer/business product that's in an extremely competitive marketplace. HN can do an incredible amount of easy caching. Besides a small box in the top right with user profile info, the entire page is completely identical for everyone.
- frosted-flakes 5y agoOnly for logged-out users. Logged-in users need to show votes, reply links, etc.
- deleted 5y ago[deleted]
- throwaway81523 5y agoLook at okws.org sometime. It gave okcupid a significant cost advantage over competitors by letting them run on a lot less hardware. I've never used it but have always admired it.