@sun @PurpCat @phnt @matrix I still have no idea what’s going on with your servers. It’s not expected performance.

@lain @PurpCat @phnt @matrix its ok right now, the current issue is a bug in pleroma when unauthenticated access to local objects is disabled it kills some federation

@sun @PurpCat @phnt Yeah, only option Misskey has for scaling is a slave db and multiple redis servers

@phnt @PurpCat @matrix @sun Multiple nodes that still have a single bottleneck in form of pumping I/O back and forth between the node and postgres.

@mint @PurpCat @matrix @sun You can loadbalance multiple postgres nodes in a read scenario. And in the case of Pleroma, writing to the DB usually isn't as I/O heavy.

@mint @phnt @PurpCat @matrix @sun

> Multiple nodes that still have a single bottleneck in form of pumping I/O back and forth between the node and postgres.

if you're evenly distributing ingress traffic from the proxy to the nodes, it should (depending on lb algorithm) spread traffic evenly(ish) across the nodes then down the io tunnel to pg. if the pg node had a low latency link (ie same network/lan) i/o should be less of an issue i would think.

i recently experimented with pleroma on kubernetes with an out of band pg backend over wireguard (local, not via vps) and threw stressor on it. performance was pretty good tbh

@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 @feld @matrix @lain I also remember graf talking about failover Pleroma (Rebased at that time) nodes he has set up. Same with Postgres. So in this one specific case, he almost does run multi-node.

@phnt @PurpCat @feld @matrix @lain they basically just threw huge hardware at it, I think the biggest gain they got was from dedicated db server

@sun @PurpCat @feld @matrix @lain The point of it all was self-healing I think, so graf doesn't have to touch anything most of the time.

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

@feld The same with Misskey! @PurpCat @phnt @matrix @lain @sun

@adiz @feld @PurpCat @phnt @lain @sun Is it? Misskey has like 5 active forks

@matrix Yeah, but they all come back home to vanilla stock Misskey at the end. Misskey's graveyard of dead forks and instances-built-upon-dead-forks is vast. @feld @PurpCat @phnt @lain @sun

@adiz @phnt @feld @matrix @lain @sun pov: you use Sharkey

@PurpCat I sometimes still come across Firefish or even Calckey instances still. @phnt @feld @matrix @lain @sun

@feld @PurpCat @phnt @sun I see, that's much better than redis

@matrix @PurpCat @phnt @sun also, if you still really really wanted to use Redis then Nebulex supports using it as a backend without really needing you to make any code changes, so it would give flexibility for people