[like_any_other]

> However, it should be obvious that if the traffic levels spiked higher by 3x to ~120 events/s - then 75% of the worker’s time would be spent simply listening to traffic

For a 4GHz CPU core, with 4 instructions-per-clock, that works out to 100 million instructions per 'event'. That is efficiency so farcically low I can only attribute it to self-sabotage.. so they can sell the Pro version.

[airhangerf15]

Yea, it's obviously a move away from open source. The FOSS tools are surely to turn to garbage. They killed of Dendrite (the re-implementation of the Matrix server in Go). People have made some clients, but I don't think there are any alternative implementations.

This is sad. The Matrix protocol will no never be XMPP. I hope Element is happy, because they're never going to be Slack. They're now stuck in a position where they are mediocre garbage to all sides.

Of course the post mentions government. Who else would buy an overpriced garbage product.

[malwrar]

I read this post as more of an “oh shit, idk who is running these projects but if you are reading this and developing a big deployment it’s going to be expensive and broken and make us all look bad. Please just spend your org’s $$$ for our rust rewrite that will make your graphs pretty and bosses smile”. The target audience feels pretty narrow for this post.

I’m also wary of such FOSS -> fee transitions, but I think this one is benign. I’m hoping these folks obtain this funding.

[Arathorn]

I wrote the OP, and this is very much the correct interpretation. I spelt out the problem more clearly here: https://mastodon.matrix.org/@element/113843808583376704

The issue is that large system integrators offer to run huge Matrix deployments for governments, think they can do so by using the FOSS server and maintain it themselves, and have no incentive to route any $ to the upstream project at all. As a result, you end up with situations like https://www.heise.de/news/Probleme-mit-Open-Source-Videokonf... where the project fails, which makes everyone look bad.

So the point of this (pretty brutal) post is to try to say: "Seriously, if you are trying to run millions of users on a deployment, work with us as the upstream project - out of the box, the FOSS project will not work for this use case".

[Arathorn]

Nope, it's not self-sabotage - the worker is sitting there consuming the events from redis, and then pulling in the dependent data from the DB and populating and maintaining its caches (and marshalling & unmarshalling the necessary data) so that it can actually do work on the events as needed.

Obviously one could certainly optimise it more... which is why we did, by rewriting it in Rust, and adding in smarter pubsub, etc.

However, the key thing is that for anything other than huge deployments, this isn't a bottleneck. But for huge deployments, it becomes one. Meanwhile, we're hoping to use $ from Synapse Pro to fund perf improvements for normal FOSS Synapse and Matrix - e.g. algorithmically improving state resolution to be more performant; finishing faster room joins; improving federation traffic routing etc... so that smaller deployments get faster anyway without needing the faster workers.