diff --git a/develop/print.html b/develop/print.html index dd4487e66b..a72ef046f8 100644 --- a/develop/print.html +++ b/develop/print.html @@ -4663,6 +4663,29 @@ on this homeserver.

allow_device_name_lookup_over_federation: true
 

+

federation

+

The federation section defines some sub-options related to federation.

+

The following options are related to configuring timeout and retry logic for one request, +independently of the others. +Short retry algorithm is used when something or someone will wait for the request to have an +answer, while long retry is used for requests that happen in the background, +like sending a federation transaction.

+ +

Example configuration:

+
federation:
+  client_timeout: 180s
+  max_short_retry_delay: 7s
+  max_long_retry_delay: 100s
+  max_short_retries: 5
+  max_long_retries: 20
+
+

Caching

Options related to caching.


@@ -15380,7 +15403,7 @@ present this information through a series of pretty graphs.

image

Still, it's probably worth investigating why we're getting users from the database that often, and whether it's possible to reduce the amount of queries we make by adjusting our cache factor(s).

The persist_events transaction is responsible for saving new room events to the Synapse database, so can often show a high transaction duration.

-

Federation

+

Federation

The charts in the "Federation" section show information about incoming and outgoing federation requests. Federation data can be divided into two basic types: