There was a period on an hour where we migrated our database to it’s own server in the same data centre.
This server has faster CPUs than our current one, 3.5GHz v 3.0GHz, and if all goes well we will migrate the extra CPUs we bought to the DB server.
The outage was prolonged due to a PEBKAC issue. I mistyped an IP in our new postgres authentication as such I kept getting a “permission error”.
The decision of always migrating the DB to it’s own server was always going to happen but was pushed forward with the recent donations we got from Guest on our Ko-Fi page! Thank-you again!
If you see any issues relating to ungodly load times please feel free to let us know!
Cheers,
Tiff
Huh. I don’t think I got a notice for this reply. So, sorry I didn’t respond – I didn’t see it! (Just saw this randomly while checking your profile to see if there was a thread regarding the “next” interface.)
Haven’t checked again thoroughly yet today, but the timings I saw yesterday matched your averages pretty well and I definitely saw a reduction in lag spikes after your other reply. I also did a fair bit of poking around with my browser’s network inspector – and I found a potential issue.
It looks like mlmym (the “old” interface – which is the primary one I use) does not set Cache-Control on pages it serves, so you may be getting traffic to your backend for every logged out lurker and scraper hitting that interface instead of letting your CDN handle it. The header is set for images and such, but not the pages themselves. Lemmy’s default UI sets it (
public, max-age=60for logged out users,privatefor logged in users). The “next” interface seems like it sets it toprivate, no-cache, no-store, max-age=0, must-revalidatefor logged out users, which is probably not ideal… I’m not sure yet what the other interfaces are doing since they’re JS heavy and I haven’t dug into them as much.