For the technically minded, we went from a t3a.small EC2 instance to an m6a.large. Both are dual-core instances, but the t3a.small type is on AMD’s Zen 1 architecture, while m6a.large is Zen 3 based, which is light years ahead (this is the equivalent of swapping out a Ryzen 1600 to a 5600X). On top of that, on the T instances you’re expected to only use 20% of the CPU and there’s a pretty heavy surcharge if you continuously use more, while on the M instances you just get the whole thing, so hosting costs are actually projected to be lower even with the jump in CPU capacity, plus we enjoy a nice jump from 2 GB of memory to 8 GB.
And yeah, while the conventional wisdom is that burstable instances are a great fit for web services, we actually have a remarkably flat CPU load. I’m thinking it’s probably federation that drives most of it it rather than direct usage of the site. I’m also fairly sure a c6a.large instance would be more cost-effective (it’s basically the same thing with half the memory for 12% cheaper) but that’s something to maybe figure out later.
hella nice!
if it ever starts acting up again just ping me, because over here on the web interface it took a while to notice the issue
Hi! It seems there is some instabilities on your instance, for the past few days there has been short periods of time where the server responds with 500 errors or just timeouts, were you aware of this?
yep, noticed it a week or two back. it’s also generating a whole bunch in hosting costs, so i already sourced a better server (a bare metal Ryzen 3700X instance with 64 GB of ECC memory) but i’m a bit time-constrained right now and bringing the instance over to this one will take a bit longer than the two clicks experience of AWS. i’m fixing this asap though, and sorry for the inconvenience until then