3 ms·

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 pr

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.

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.