1 files changed, 1 insertions, 24 deletions
diff --git a/develop/print.html b/develop/print.html
index 1e4fe2b4b7..6e1e9d1859 100644
--- a/develop/print.html
+++ b/develop/print.html
@@ -4663,29 +4663,6 @@ 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 in seconds. Default to 60s.</li>
-<li><code>max_short_retry_delay</code>: maximum delay to be used for the short retry algo in seconds. Default to 2s.</li>
-<li><code>max_long_retry_delay</code>: maximum delay to be used for the short retry algo in seconds. 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: 180
- max_short_retry_delay: 7
- max_long_retry_delay: 100
- 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 />
@@ -15404,7 +15381,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-2"><a class="header" href="#federation-2">Federation</a></h2>
+<h2 id="federation-1"><a class="header" href="#federation-1">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>
|
