kaslo/synapse
1
0
Fork 0
Code Wiki Activity

deploy: 32fc3b7ba4

Browse Source
This commit is contained in:
erikjohnston
2022-09-06 07:50:41 +00:00
parent cb59d5b4d2
commit 8c05b5f9d7
6 changed files with 38 additions and 42 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
develop/workers.html
View File

@@ -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>