1 files changed, 24 insertions, 1 deletions
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.</p>
<pre><code class="language-yaml">allow_device_name_lookup_over_federation: true
</code></pre>
<hr />
+<h3 id="federation-1"><a class="header" href="#federation-1"><code>federation</code></a></h3>
+<p>The federation section defines some sub-options related to federation.</p>
+<p>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.</p>
+<ul>
+<li><code>client_timeout</code>: timeout for the federation requests. Default to 60s.</li>
+<li><code>max_short_retry_delay</code>: maximum delay to be used for the short retry algo. Default to 2s.</li>
+<li><code>max_long_retry_delay</code>: maximum delay to be used for the short retry algo. Default to 60s.</li>
+<li><code>max_short_retries</code>: maximum number of retries for the short retry algo. Default to 3 attempts.</li>
+<li><code>max_long_retries</code>: maximum number of retries for the long retry algo. Default to 10 attempts.</li>
+</ul>
+<p>Example configuration:</p>
+<pre><code class="language-yaml">federation:
+ client_timeout: 180s
+ max_short_retry_delay: 7s
+ max_long_retry_delay: 100s
+ max_short_retries: 5
+ max_long_retries: 20
+</code></pre>
+<hr />
<h2 id="caching"><a class="header" href="#caching">Caching</a></h2>
<p>Options related to caching.</p>
<hr />
@@ -15380,7 +15403,7 @@ present this information through a series of pretty graphs.</p>
<p><img src="https://user-images.githubusercontent.com/1342360/82240467-62030100-9932-11ea-8db9-917f2d977fe1.png" alt="image" /></p>
<p>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).</p>
<p>The <code>persist_events</code> transaction is responsible for saving new room events to the Synapse database, so can often show a high transaction duration.</p>
-<h2 id="federation-1"><a class="header" href="#federation-1">Federation</a></h2>
+<h2 id="federation-2"><a class="header" href="#federation-2">Federation</a></h2>
<p>The charts in the "Federation" section show information about incoming and outgoing federation requests. Federation data can be divided into two basic types:</p>
<ul>
<li>PDU (Persistent Data Unit) - room events: messages, state events (join/leave), etc. These are permanently stored in the database.</li>
|
