Fix typos in documentation (#12863)

This commit is contained in:
Dirk Klimpel 2022-05-25 11:14:03 +02:00 committed by GitHub
parent e7c77a8750
commit 298911555c
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
4 changed files with 4 additions and 3 deletions

1
changelog.d/12863.doc Normal file
View file

@ -0,0 +1 @@
Fix typos in documentation.

View file

@ -117,7 +117,7 @@ In this example, we define three jobs:
Note that this example is tailored to show different configurations and Note that this example is tailored to show different configurations and
features slightly more jobs than it's probably necessary (in practice, a features slightly more jobs than it's probably necessary (in practice, a
server admin would probably consider it better to replace the two last 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 `max_lifetime` is greater than 3 days). policy's `max_lifetime` is greater than 3 days).
Keep in mind, when configuring these jobs, that a purge job can become Keep in mind, when configuring these jobs, that a purge job can become

View file

@ -43,7 +43,7 @@ loggers:
The above logging config will set Synapse as 'INFO' logging level by default, 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. with the SQL layer at 'WARNING', and will log to a file, stored as JSON.
It is also possible to figure Synapse to log to a remote endpoint by using the It is also possible to configure Synapse to log to a remote endpoint by using the
`synapse.logging.RemoteHandler` class included with Synapse. It takes the `synapse.logging.RemoteHandler` class included with Synapse. It takes the
following arguments: following arguments:

View file

@ -1,6 +1,6 @@
# Scaling synapse via workers # Scaling synapse via workers
For small instances it recommended to run Synapse in the default monolith mode. 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 For larger instances where performance is a concern it can be helpful to split
out functionality into multiple separate python processes. These processes are out functionality into multiple separate python processes. These processes are
called 'workers', and are (eventually) intended to scale horizontally called 'workers', and are (eventually) intended to scale horizontally