>Pleroma gets crippled by simply getting accessed too much

Pleroma does what Mastodont

@matrix if you saw my logs you'd see how fast it was and how many there were.

@matrix but yeah I don't really know why it's not so bad for mastodon comparably

@sun What seems to be the bottleneck?
My uneducated guess is that it's just bad DB design because I never saw a DB bottleneck with Mastodon.
What I usually saw was just requests not getting fulfilled fast enough because Ruby is slow and that was always solved by more processes and more CPU and RAM. SPW is on a dedi right?

@sun I think only large instances like Pawoo and MatSoc probably need a secondary read only db, while I remember p having to deploy one for FSE

@matrix @sun It doesn't help that Pleroma was probably never designed to withstand the traffic it does now. It was meant to be a straightforward AP implementation and the DB reflects that. It doesn't attempt a bunch of normalization of objects
into colums, it shoves the whole object into a jsonb column and calls it a day.

The DB schema is quite performant anyway, the sizes of indexes are the issues usually.

@phnt @matrix @sun pleroma was also designed when the fedi network was smaller and you were running it on a rpi or some shit and it's clear the devs are pandering to the crowd that will just run a pds in the bsky gated community anyhow

@PurpCat @phnt @sun Isn't Mastodon older?

@matrix @PurpCat @phnt mastodon was built from the ground up for scaling, you can argue about how good it is but the attempt was made

@sun @PurpCat @phnt Pleroma should ideally be better at scaling because of Erlang

@matrix @sun @PurpCat feld had an almost working prototype for multiple nodes at some point I think. There was an issue with Cachex I think and that was it.

@phnt @PurpCat @matrix @sun oh yeah we just need to replace Cachex and it's not hard, I just ended up moving and other priorities stacked up

@feld @PurpCat @phnt @sun why not Redis/Valkey? Is it to minimize dependencies?

@matrix @PurpCat @phnt @sun there is a cluster native caching mechanism available to use which has a beautifully simply syntax because you just decorate the functions you want to cache and which ones to bust the cache. Then you also configure which caches should be independent per node and which should be shared across the cluster

https://hexdocs.pm/nebulex/Nebulex.Caching.Decorators.html

@matrix @PurpCat @phnt @sun also yes the main reason for not using redis/valkey is that it's an unnecessary dependency when this type of functionality is core to the language already and it will just perform better because the OS doesn't need to context switch to access the cache

@feld @PurpCat @phnt @matrix @sun tbh there are zero currently active pleroma instances that would need to run distributed on multiple nodes.

@lain @PurpCat @phnt @feld @matrix did you know poa.st is on stock pleroma now

@sun @PurpCat @phnt @matrix @lain they all come home eventually