3 ms·

I'd first wish the services would be written so that they do not use too much CPU to begin with. Ruby is horrendous with CPU usage, and the concurrency/threadin

by pimeys 4y ago

I'd first wish the services would be written so that they do not use too much CPU to begin with. Ruby is horrendous with CPU usage, and the concurrency/threading in Ruby runtime is nothing to brag about. A service such as a small community Fediverse server does not need microservices and complex architecture. What I've been seeing, people are kind of struggling with Ruby and Sidekiq even when having servers that are not super big. In the past, WhatsApp was having a small group of engineers with a handful of servers, serving hundreds of millions of users with Erlang. To get people running their own Fediverse servers, it should be as easy and as cheap as possible. Akkoma is a good start, and in a few months I hope we see the first proper systems made with Rust and Go, running with the minimal amount of resources, being single process and federating everything without the user needing to do any maintenance.

rektide 4y ago
I dont disagree on any point. I would still pick an implementation where I have control, management, & observability of the separate processes, such that I can see & trade off where resources are going. Mastadon aint fast, but, this current architecture has been invaluable in letting folks degrade gracefully. Sidekiq for ingress gets backed up, but often the web service is totally responsive and egress sidekiq (if seperately configured) works fine. Picking a more effective runtime might give you a lot more headroom, but I'd still want a plan & ability to cope & degrade gracefully when the system does come under pressure, and Im not sure Erlang/Beam or any other single process system is going to have such innate ability to have the different things dealt with differently. Bulkhead pattern is a truly great one- keep the whole ship from sinking when one part floods. https://learn.microsoft.com/en-us/azure/architecture/patterns/bulkhead https://learn.microsoft.com/en-us/azure/architecture/pattern...

by pimeys 4y ago

rektide 4y ago

I dont disagree on any point. I would still pick an implementation where I have control, management, & observability of the separate processes, such that I can see & trade off where resources are going. Mastadon aint fast, but, this current architecture has been invaluable in letting folks degrade gracefully. Sidekiq for ingress gets backed up, but often the web service is totally responsive and egress sidekiq (if seperately configured) works fine. Picking a more effective runtime might give you a lot more headroom, but I'd still want a plan & ability to cope & degrade gracefully when the system does come under pressure, and Im not sure Erlang/Beam or any other single process system is going to have such innate ability to have the different things dealt with differently. Bulkhead pattern is a truly great one- keep the whole ship from sinking when one part floods. https://learn.microsoft.com/en-us/azure/architecture/patterns/bulkhead https://learn.microsoft.com/en-us/azure/architecture/pattern...