At the time of writing, Lemmyworld has the second highest number of active users (compared to all lemmy instances)
Also at the time of writing, Lemmyworld has >99% uptime.
By comparison, other lemmy instances with as many users as Lemmyworld keep going down.
What optimizations has Lemmyworld made to their hosting configuration that has made it more resilient than other instances’ hosting configurations?
See also Does Lemmy cache the frontpage by default (read-only)? on !lemmy_support@lemmy.ml
Right, but if you don’t have a cache setup, then the DB gets taxed. At a certain point a cache looses its benefit, but an enormous amount of savings can be made (to backend DB calls, for example) by just caching all API reads for ~60 seconds.
Ensuring there’s no data leakage in those cached calls can be tricky, especially if any api calls return anything sensitive (login tokens, authentication information, etc) but I can see caching all read-only endpoints that return the same data regardless of permissions for a second or two being helpful for the larger servers.
It’s also worth noting that postgres does its own query-level caching, quite aggressively too. I’ve worked in some places where we had to add a SELECT RANDOM() to a query to ensure it was pulling the latest data.
In my experience, the best benefits gained from caching are done before the backend and are stored in RAM, so the query never even reaches those services at all. I’ve used varnish for this (which is also what the big CDN providers use). In Lemmy, I imagine that would be the ngnix proxy that sits in-front of the backend.
I haven’t heard admins discussing web-proxy caching, which may have something to do with the fact that the Lemmy API is currently pretty much entirely over websockets. I’m not an expert in web-sockets, and I don’t want to say that websockets API responses absolutely can’t be cached… but it’s not like caching a restful API. They are working on moving away from websockets, btw… but it’s not there yet.
The comments from Lemmy devs in https://github.com/LemmyNet/lemmy/issues/2877 make me think that there’s a lot of database query optimization low-hanging fruit to be had, and that admins are frequently focusing on app configs like worker counts and db configs to maximize the effectiveness of db-level caches, indexes, and other optimizations.
Which isn’t to say there aren’t gains in the direction your suggesting, but I haven’t seen evidence that anyone’s secret sauce is in effective web-proxy caches.
