1
0
Fork 0
mirror of https://git.sr.ht/~seirdy/seirdy.one synced 2024-12-26 18:32:10 +00:00
seirdy.one/content/notes/matrix-performance-problems.md
Seirdy 578db97542
Fix broken links
Remove moonshot pending link as the site cert seems expired and it looks
abandoned
2024-05-24 18:31:14 -04:00

1.5 KiB

title date replyURI replyTitle replyType replyAuthor replyAuthorURI
Matrix performance problems 2022-11-15T12:23:28-08:00 https://web.archive.org/web/20221209081125/https://fedi.lucdev.net/notice/APdYWfzd59CNH2QCem I cannot seem to join big [Matrix] rooms; it seems the software is not efficient SocialMediaPosting Luc https://lucdev.net

Synapse is incredibly slow, which is why I run the Conduit matrix server. Server performance is the main price paid for Matrix' history replication.

This also gives Matrix a spam DDoS problem: sometimes people mass-create accounts on hundreds of servers with open registration, and mass-join rooms. The flood of thousands of join-events will OOM most connected servers. My Conduit server (RocksDB backend, 1 vCPU, 1GB RAM) is actually fast and light enough to ride some of these out and go back to normal speeds a couple hours after the floods die down.

You generally don't want to join a room like Matrix-HQ unless you have good hardware. A new Postgres backend is coming to Conduit soon, which should improve the situation.

Once Conduit implements a few missing features (federated backfill, spaces hierarchy and room discovery), and once better spam controls roll out (e.g. automatically restricting joins to under N per second and/or automatically blocking open-registration servers during high join frequencies), I'd say the worst performance problems will be gone.