Well client-side there seems to be progress but to my knowledge so far Riot was the only feature-complete client, and it's REALLY heavy/slow especially on high-latency links. Loading app.element.io before logging in is already 9MB. Also element responsiveness in general is really tied to latency and is therefore not pleasant to use on bad connections and/or Tor.

Server-side, many smaller hosting coops went into matrix but later dropped it because of synapse using too much resources. I know individual selfhosters who were really sad to drop it because their raspberry pi didn't have enough RAM (512MB-1GB) for selfhosting synapse.

However someone said in another thread that synapse resource usage is really better these days. Would you recommend it on such low-end hardware? (ActivityPub/XMPP servers fare really well in such conditions)

The thing that eats the most resources is joining very large, public Matrix rooms. If you don't do this, it won't be resource heavy.

I've heard of people running Synapse on a RPi 3 (see https://old.reddit.com/r/selfhosted/comments/g9h6au/matrixri... for instance) for such use cases. If you want to chat in large 1000+ member rooms, it probably won't be enough. However, even for such a use case, you don't need anything that is out of reach of a common person, just a few gigabytes of RAM. In general, it's hard to make it go over 3 GiB. My server hovers around 2 GiB and I'm in many large rooms, including the beast that is Matrix HQ.

So I would agree that Synapse is not usable on RPi-level hardware in all use cases, but you can definitely run it on such hardware for some use cases. Dendrite is also maturing really quickly and will be less resource hungry.

Also, element-desktop 1.7.21 SEGFAULTs during startup on my Debian machine. Would rather it didn't. Wow:

  $ ldd `which element-desktop` | wc -l
  102

Is it not just an electron? I would see if you can anbox the APK. Although the stock Debian kernel is not up to task. Need to turn the Android knobs. Binder and ashmem.

please file a bug report if you haven’t already so we can hunt the problem; i’m unaware of this.

Hey, what smaller hosting coops are out there? I'm a member at hcoop.net, wondering what else like us is out there.

You could be interested to checkout libreho.st and chatons.org, who are two generic hosting coops federations. tildeverse.org is a third one centered around PUBNIXes, that is servers giving away shell accounts specifically.

We're < 5 users on my synapse server running on a modern mid-range 6c/12t CPU. 4GB DDR4-2966 RAM dedicated to synapse. It has a separate decently fast postgres cluster for the db. Only 2000 rooms.

It's frustratingly slow and heavy, regardless of client.

Perf problems arise with Synapse if those 2000 rooms include massive ones with tens or hundreds of thousands of users (or other state events). The number of local users is fairly irrelevant.

If you grep the logs for state-res you will probably see that some room is consistently chewing resources (these days we explicitly log the worst offenders); easiest bet is to ask your users to leave that room or use the shutdown api to remove it from the server.

Otherwise, it may be that there’s so much data flying around due to the busy rooms that the in-memory caches are blowing out. This makes everything slow down as the DB gets hammered, and unintuitively uses more RAM as slow requests stack up. The solution is to increase the cache factor, much as you would on an overloaded db. We’re currently looking at autotuning caches do you don’t have to do this manually.

If it’s still slow, then there’s probably a bug or other weirdness (ancient Python?) - my personal server has about 5 users on a 4 core cpu and uses about 2GB of RAM without a dedicated DB node and is in thousands of rooms (including busy ones).

(Also it hopefully goes without saying that all bets are off if you aren’t on the latest Synapse release - we are constantly landing improvements currently; eg the auth chain cover algorithm eliminates most of the known perf edge cases on state resolution).

Thanks for the pointers - on latest release with Python 3.8 and roughly 2~5 of those rooms are on the larger ends of the spectrum.

Sounds like I should tune some caches then - I have memory to spare if it turns out to make a difference.

BTW, I just noticed there is an option to add a Redis - would that be a significant improvement compared to just using the process caching?

So you’ll want to try dialling up the overall cache factor a bit.

Redis is only useful if you split the server into multiple worker processes, which you shouldn’t need to at that size (and even then, doesn’t provide shared caching yet, although there’s a PR in flight for it - we currently just use redis as a pubsub mechanism between the workers).

Highly recommend hooking up prometheus and grafana if you haven’t already, as it will likely show a smoking gun of whatever the failure mode is.

Are the logs stacking up with slow state-res warnings? Stuff like:

    2021-02-25 23:15:26,408 - synapse.state.metrics - 705 - DEBUG - None - 1 biggest rooms for state-res by CPU time: ['!YynUnYHpqlHuoTAjsp:matrix.org (34.6265s)']
    2021-02-25 23:15:26,411 - synapse.state.metrics - 705 - DEBUG - None - 1 biggest rooms for state-res by DB time: ['!YynUnYHpqlHuoTAjsp:matrix.org (148.6s)']