|
|
|
|
|
by chrisldgk
464 days ago
|
|
For things like this (public facing static sites) I’ve often gone for a pretty naive approach using Redis (more lately KeyDB as a drop-in alternative) to cache any static pages that SSR would be handling otherwise for a minute or so. If I needed any more performance I’d also use node:cluster to run the server on multiple threads.
This significantly improved RPS while keeping CPU usage lower because I had found that my bottleneck for most of these problems was database lookups (Postgres mostly, specifically rerequsting the same data). The big convenience that SSR brings for most of my use cases is querying the CMS for changes and getting instant updates on the frontend without having to statically rebuild the HTML anytime content is updated. That approach allowed me to run SSR without all the performance issues it would bring otherwise. I don’t have exact numbers but I can provide them if anyone’s interested. |
|