Hello all,
Apologies if this isn’t the right place, but I have moved instances a few times, and in doing so I’ve accumulated a number of subscriptions from my old instances. I always used the “migrate” feature, and I have roughly 200 communities I’m subscribed to. Most are from various other instances that aren’t my own. That being said, I have Lemmy open on “subscribed” and “scaled”, as I found this gives me just what I want to see when I boot up the site.
But it is very slow, sometimes even timing out on Jerboa. I thought it was my instance, but I’ve had this issue on other instances as well. I’d imagine federating all my subscriptions would take some time, but then wouldn’t “All” cause even more problems? I’ve tried to look into this to no avail.
Am I the only one? I’m asking this more out of curiosity than an actual solution.
This is probably true for anonymous (not logged in) users, but might not be if you are logged in. Things like user/community/instance blocks, votes, read/unread status, etc. need to be accounted for when generating the main feed for logged in users, and those are dynamic. It might be cached for some time, but the retention time would likely be short (a couple minutes maybe).
I haven’t worked too much with the caching that piefed does, but I know it keeps some info in a redis cache to help speed things up (blocks, votes, etc.). That way getting all that info doesn’t need to be a new db query every time except maybe the first time. Some pages also make use of etags so that if the content is unchanged, the request doesn’t need to hit the db at all. I imagine lemmy has some mechanisms to do caching as well, but I am unfamiliar with the code at that level.
It’s likely much faster to fetch the common feed from the database cache or prepared cache like Redis, and apply all this additional data in the app, than do uncached joins. So I’d hope that the apps do this. Especially since you say they use Redis, which of course doesn’t do joins and such, unless something changed in the past years.