From c41ea155f2f1297e6141335704e47e2d61b4938e Mon Sep 17 00:00:00 2001 From: Hans van Zijst Date: Sun, 22 Dec 2024 16:49:20 +0100 Subject: [PATCH] Added introduction and PostgreSQL warning. --- matrix/synapse/workers.md | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/matrix/synapse/workers.md b/matrix/synapse/workers.md index bf5e021..8654bda 100644 --- a/matrix/synapse/workers.md +++ b/matrix/synapse/workers.md @@ -3,7 +3,7 @@ gitea: none include_toc: true --- -# Worker-based setup +# Introduction to a worker-based setup Very busy servers are brought down because a single thread can't keep up with the load. So you want to create several threads for different types of work. @@ -22,6 +22,27 @@ freeze the rest. Workers communicate with each other via socket files and Redis. +**Important note** + +While the use of workers can drastically improve speed, the law of diminished +returns applies. Splitting off more and more workers will not further improve +speed after a certain point. Plus: you need to understand what the most +resource-consuming tasks are before you can start to plan how many workers for +what tasks you need. + +In this document we'll basically create a worker for every task, and several +workers for a few heavy tasks, as an example. You mileage may not only vary, it +will. + +Tuning the rest of the machine and network also counts, especially PostgreSQL. +A well-tuned PostgreSQL can make a really big difference and should probably +be considered even before configuring workers. + +With workers, PostgreSQL's configuration should be changed accordingly: see +[Tuning PostgreSQL for a Matrix Synapse +server](https://tcpipuk.github.io/postgres/tuning/index.html) for hints and +examples. + # Redis