mirror of
https://github.com/element-hq/synapse
synced 2024-08-19 06:50:52 +00:00
deploy: 298911555c
This commit is contained in:
parent
a7da1f9e6d
commit
088d0fbd69
6 changed files with 8 additions and 8 deletions
|
@ -239,7 +239,7 @@ policy's <code>max_lifetime</code> is greater than a week.</li>
|
|||
<p>Note that this example is tailored to show different configurations and
|
||||
features slightly more jobs than it's probably necessary (in practice, a
|
||||
server admin would probably consider it better to replace the two last
|
||||
jobs with one that runs once a day and handles rooms which which
|
||||
jobs with one that runs once a day and handles rooms which
|
||||
policy's <code>max_lifetime</code> is greater than 3 days).</p>
|
||||
<p>Keep in mind, when configuring these jobs, that a purge job can become
|
||||
quite heavy on the server if it targets many rooms, therefore prefer
|
||||
|
|
|
@ -9118,7 +9118,7 @@ loggers:
|
|||
</code></pre>
|
||||
<p>The above logging config will set Synapse as 'INFO' logging level by default,
|
||||
with the SQL layer at 'WARNING', and will log to a file, stored as JSON.</p>
|
||||
<p>It is also possible to figure Synapse to log to a remote endpoint by using the
|
||||
<p>It is also possible to configure Synapse to log to a remote endpoint by using the
|
||||
<code>synapse.logging.RemoteHandler</code> class included with Synapse. It takes the
|
||||
following arguments:</p>
|
||||
<ul>
|
||||
|
@ -11051,7 +11051,7 @@ policy's <code>max_lifetime</code> is greater than a week.</li>
|
|||
<p>Note that this example is tailored to show different configurations and
|
||||
features slightly more jobs than it's probably necessary (in practice, a
|
||||
server admin would probably consider it better to replace the two last
|
||||
jobs with one that runs once a day and handles rooms which which
|
||||
jobs with one that runs once a day and handles rooms which
|
||||
policy's <code>max_lifetime</code> is greater than 3 days).</p>
|
||||
<p>Keep in mind, when configuring these jobs, that a purge job can become
|
||||
quite heavy on the server if it targets many rooms, therefore prefer
|
||||
|
@ -12182,7 +12182,7 @@ changes to the database should now be made by the module using the module API cl
|
|||
use the new <code>modules</code> section in Synapse's configuration file (see <a href="modules/index.html#using-modules">this section</a>
|
||||
for more info).</p>
|
||||
<div style="break-before: page; page-break-before: always;"></div><h1 id="scaling-synapse-via-workers"><a class="header" href="#scaling-synapse-via-workers">Scaling synapse via workers</a></h1>
|
||||
<p>For small instances it recommended to run Synapse in the default monolith mode.
|
||||
<p>For small instances it is recommended to run Synapse in the default monolith mode.
|
||||
For larger instances where performance is a concern it can be helpful to split
|
||||
out functionality into multiple separate python processes. These processes are
|
||||
called 'workers', and are (eventually) intended to scale horizontally
|
||||
|
|
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
|
@ -183,7 +183,7 @@ loggers:
|
|||
</code></pre>
|
||||
<p>The above logging config will set Synapse as 'INFO' logging level by default,
|
||||
with the SQL layer at 'WARNING', and will log to a file, stored as JSON.</p>
|
||||
<p>It is also possible to figure Synapse to log to a remote endpoint by using the
|
||||
<p>It is also possible to configure Synapse to log to a remote endpoint by using the
|
||||
<code>synapse.logging.RemoteHandler</code> class included with Synapse. It takes the
|
||||
following arguments:</p>
|
||||
<ul>
|
||||
|
|
|
@ -147,7 +147,7 @@
|
|||
</div>
|
||||
|
||||
<h1 id="scaling-synapse-via-workers"><a class="header" href="#scaling-synapse-via-workers">Scaling synapse via workers</a></h1>
|
||||
<p>For small instances it recommended to run Synapse in the default monolith mode.
|
||||
<p>For small instances it is recommended to run Synapse in the default monolith mode.
|
||||
For larger instances where performance is a concern it can be helpful to split
|
||||
out functionality into multiple separate python processes. These processes are
|
||||
called 'workers', and are (eventually) intended to scale horizontally
|
||||
|
|
Loading…
Reference in a new issue