5 ms·

Author named ~70k hits per day. If we calculate 72000/12 that's 6000 - which is 1.6 req/s. Why are we talking about "surviving" anything here? Here some number

• xuki 5y ago
  People see servers with multi Gbps and think it’s a requirement for high traffic websites. Unless you’re serving videos, bandwidth is almost never the bottleneck.
  • Nextgrid 5y ago
    High bandwidth protects you against basic DoS attacks that just fill up the pipe with garbage traffic. The other problem is that bandwidth is usually harder to scale than let's say CPU or memory, so having a large buffer there is helpful. Let's say the aforementioned VPS is suddenly under a lot of CPU load and legitimately can't keep up - Nginx can be trivially installed on it to load-balance between many downstream VPSes. Now let's say you are running out of bandwidth. You may need to switch to a different connection with a different IP, change DNS records and wait for them to propagate, etc.
• hddherman 5y ago
  It's mainly down to these points: * I've seen a lot of sites fall over when posted on HN or other link aggregators, like Reddit. * Cloud providers advertise gigabit or bigger pipes for networking, 50 Mbps is not a lot in comparison. * Images and other assets can take up a good chunk of this available bandwidth, which is why I keep an eye on the size of the end result as well. * It's fun.
  • wink 5y ago
    It's a good article, please don't get me wrong here. I was just a little confused after doing the math. I'd imagine a very image-heavy post might be more of a bandwidth problem, but yeah, definition of "website" and all. My only nitpick (and sorry if I missed it, skimming) was the focus on total requests - which I find kinda useless, you need to look at resolution per minute, or per seconds for peaks.
• jerf 5y ago
  This is what it boils down to: Serving web pages in 2022 is easy. A raspberry pi is seriously overpowered for the task, even for dynamic web pages. 15 years ago, well into the WWW revolution, it would be considered not only server-class performance, but serious server-class performance. (It wouldn't be server-grade hardware... missing redundancy, etc., although if they could have picked them up for ~$50 instead of ~$5000 they would have just bought more and dealt with it.) Massive websites have been run on far less. You have to work really hard to take even a low-end laptop's worth of hardware and make a website that is slow to serve. You have to run Apache in a bad configuration that holds connections open too long. You have to make queries to a database that aren't correctly indexed so they're all table scans, and you have to make a lot of them. You have to serve huge amounts of crap to the user that is poorly optimized for their browser. You have to serve incorrectly-compressed images and videos. You have to design for a microservice architecture internally where everything's synchronous calls and some of the calls are overloaded and you don't notice, or there are messages busses you're using that are backed up, or something like that. You don't have to do all of those at once, but you need to do a few of them because modern hardware will still blast through serving if you just have a couple of those problems. However, there are programmers, design teams, managers, and frameworks up to the task. Frameworks that enable query flurries. Programmers that don't understand the concept of query flurries and don't realize they just wrote a renderer for their home page that runs seven hundred queries just to load the username of the currently-logged in user and their most recent activity. Slow backend languages that are less "io blocked" than people realize and really are slow, especially by the time you're done stacking 3 or 4 "nifty" language features on top of each other. Leadership that mandates breaking fast monoliths into slow microservices. Marketers demanding that you put the video they provided up, as is, with no modifications, or you're fired. Front-end frameworks that are only 'blazingly fast' if you use them carefully and correctly but make it very easy to end up using dozens of components that don't work together and end up with websites that take 3 seconds just for the browser to lay them out, despite the page itself being very simple visually in the end. It's hard work to slow a web page down that much, but it turns out that the work ethic is alive and well in this segment of the economy and there's a lot of people up for it! If you're used to all this and it's just the way things are for you, and you're watching a 2022-spec server groan under the load of getting 3 pages a second, the idea that a single home computer and home connection could easily serve 100 or 1000 pages a second, or that a super-low-end cloud instance could easily serve 10,000/second, sounds like someone lying to you.