diff options
author | erikjohnston <erikjohnston@users.noreply.github.com> | 2022-09-06 07:50:41 +0000 |
---|---|---|
committer | erikjohnston <erikjohnston@users.noreply.github.com> | 2022-09-06 07:50:41 +0000 |
commit | 8c05b5f9d70eec0c67f8eccd112e0509869e0bff (patch) | |
tree | 709e82326c346f5916447e04c7d6204196369fcb /develop/workers.html | |
parent | deploy: 877bdfa889fa07d09f385df297a9282d51d50dae (diff) | |
download | synapse-8c05b5f9d70eec0c67f8eccd112e0509869e0bff.tar.xz |
deploy: 32fc3b7ba4702a0068a82bdd0595e2f426967d4d
Diffstat (limited to 'develop/workers.html')
-rw-r--r-- | develop/workers.html | 23 |
1 files changed, 6 insertions, 17 deletions
diff --git a/develop/workers.html b/develop/workers.html index edce04a8d4..21ddd59be1 100644 --- a/develop/workers.html +++ b/develop/workers.html @@ -172,13 +172,8 @@ sync with the database state.</p> stream between all configured Synapse processes. Additionally, processes may make HTTP requests to each other, primarily for operations which need to wait for a reply ─ such as sending an event.</p> -<p>Redis support was added in v1.13.0 with it becoming the recommended method in -v1.18.0. It replaced the old direct TCP connections (which is deprecated as of -v1.18.0) to the main process. With Redis, rather than all the workers connecting -to the main process, all the workers and the main process connect to Redis, -which relays replication commands between processes. This can give a significant -cpu saving on the main process and will be a prerequisite for upcoming -performance improvements.</p> +<p>All the workers and the main process connect to Redis, which relays replication +commands between processes.</p> <p>If Redis support is enabled Synapse will use it as a shared cache, as well as a pub/sub mechanism.</p> <p>See the <a href="#architectural-diagram">Architectural diagram</a> section at the end for @@ -435,8 +430,7 @@ of events, then a dedicated set of workers can be provisioned to limit the effects of bursts of events from that bridge on events sent by normal users.</p> <h4 id="stream-writers"><a class="header" href="#stream-writers">Stream writers</a></h4> <p>Additionally, the writing of specific streams (such as events) can be moved off -of the main process to a particular worker. -(This is only supported with Redis-based replication.)</p> +of the main process to a particular worker.</p> <p>To enable this, the worker must have a HTTP replication listener configured, have a <code>worker_name</code> and be listed in the <code>instance_map</code> config. The same worker can handle multiple streams, but unless otherwise documented, each stream can only @@ -649,14 +643,9 @@ equivalent to <code>synapse.app.generic_worker</code>:</p> <li><code>synapse.app.synchrotron</code></li> </ul> <h2 id="migration-from-old-config"><a class="header" href="#migration-from-old-config">Migration from old config</a></h2> -<p>There are two main independent changes that have been made: introducing Redis -support and merging apps into <code>synapse.app.generic_worker</code>. Both these changes -are backwards compatible and so no changes to the config are required, however -server admins are encouraged to plan to migrate to Redis as the old style direct -TCP replication config is deprecated.</p> -<p>To migrate to Redis add the <code>redis</code> config as above, and optionally remove the -TCP <code>replication</code> listener from master and <code>worker_replication_port</code> from worker -config.</p> +<p>A main change that has occurred is the merging of worker apps into +<code>synapse.app.generic_worker</code>. This change is backwards compatible and so no +changes to the config are required.</p> <p>To migrate apps to use <code>synapse.app.generic_worker</code> simply update the <code>worker_app</code> option in the worker configs, and where worker are started (e.g. in systemd service files, but not required for synctl).</p> |