3 ms·

"A $5/month VPS won't cut it anymore." Are you speaking from experience, or inferring from articles like this? I serve a static site on the lowest Linode $5/m

by jerf 2mo ago

"A $5/month VPS won't cut it anymore." Are you speaking from experience, or inferring from articles like this? I serve a static site on the lowest Linode $5/month VPS and it is grotesquely overprovisioned for that use case. It is not the case that every site is getting slammed every second by hundreds of requests per second. Now, if you have some sort of dynamically-computed website that is generated by a slow scripting language that is poorly optimized and hits the database too many times for a single page, yeah, it doesn't take many RPS to take you out. But that isn't the only option; it's the slowest of the slow options. Realistic, there are plenty of sites that match that description, but I concatenated that many clauses on purpose. Drop any one of them and your personal site will be fine.

marginalia_nu 2mo ago
It's almost always the DBMS that's the bottleneck when websites drop from traffic. As long as you don't do anything fancier than primary key look-ups you're probably fine though. I survived handling the search search traffic generated by this thread[1] on PC hardware off a residential broadband connection without any sort of degradation. Only time I've gone offline from traffic was when Elon Musk tweeted a link to one of my blog posts, and that was just a short temporary blip. [1] https://news.ycombinator.com/item?id=28550764 https://news.ycombinator.com/item?id=28550764
- jerf 2mo ago
  Yeah, IIRC my django site was 3 queries, all correctly indexed, for a main page hit, and 2 for the actual posts. I don't recall the exact perf numbers, but I'm pretty sure it was easily in the 50/rps range for a small dual-CPU host... which doesn't sound like much in "requests per second" but is enough to cover a front-page-HN'ing just fine. And that "rps" was just the database-backed pages, all the static content was served over nginx, so that 50rps is a "real", 50 humans per second rps, not something getting consumed by only two or three humans.
- allthetime 2mo ago
  For a “personal website” or any relatively simple static content site, the DB should not be getting hit much at all. Cache is your friend. For my sites I have a map of all relevant queries and when we do updates we run the relevant queries one time and cache them to both memory and file system.
  - marginalia_nu 2mo ago
    Should being the operative word. In practice it's both easy and common to have a database do unnecessary work when generating a page, a problem that often only rears its head when under unusual load.
    - allthetime 2mo ago
      It depends. If you don't have user accounts / user generated data I don't see why you can't completely determine all necessary content GETs. You could even go as far as to not even allow web requests to trigger database calls and have them only ever pull from cache.
messh 2mo ago
Yes! There are linux boxes that stip and resume like a lambda, but really linux. And you pay only for what you use. Look for e.g. at https://shellbox.dev https://shellbox.dev, it starts at $0.02/hr

by jerf 2mo ago

marginalia_nu 2mo ago

It's almost always the DBMS that's the bottleneck when websites drop from traffic. As long as you don't do anything fancier than primary key look-ups you're probably fine though. I survived handling the search search traffic generated by this thread[1] on PC hardware off a residential broadband connection without any sort of degradation. Only time I've gone offline from traffic was when Elon Musk tweeted a link to one of my blog posts, and that was just a short temporary blip. [1] https://news.ycombinator.com/item?id=28550764 https://news.ycombinator.com/item?id=28550764

jerf 2mo ago
Yeah, IIRC my django site was 3 queries, all correctly indexed, for a main page hit, and 2 for the actual posts. I don't recall the exact perf numbers, but I'm pretty sure it was easily in the 50/rps range for a small dual-CPU host... which doesn't sound like much in "requests per second" but is enough to cover a front-page-HN'ing just fine. And that "rps" was just the database-backed pages, all the static content was served over nginx, so that 50rps is a "real", 50 humans per second rps, not something getting consumed by only two or three humans.
allthetime 2mo ago
For a “personal website” or any relatively simple static content site, the DB should not be getting hit much at all. Cache is your friend. For my sites I have a map of all relevant queries and when we do updates we run the relevant queries one time and cache them to both memory and file system.
- marginalia_nu 2mo ago
  Should being the operative word. In practice it's both easy and common to have a database do unnecessary work when generating a page, a problem that often only rears its head when under unusual load.
  - allthetime 2mo ago
    It depends. If you don't have user accounts / user generated data I don't see why you can't completely determine all necessary content GETs. You could even go as far as to not even allow web requests to trigger database calls and have them only ever pull from cache.

messh 2mo ago

Yes! There are linux boxes that stip and resume like a lambda, but really linux. And you pay only for what you use. Look for e.g. at https://shellbox.dev https://shellbox.dev, it starts at $0.02/hr