deploy: 87e5df9a6e
				
					
				
			
							parent
							
								
									52e162c6cf
								
							
						
					
					
						commit
						fa7804d148
					
				| 
						 | 
				
			
			@ -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>
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
										
											
												File diff suppressed because one or more lines are too long
											
										
									
								
							
										
											
												File diff suppressed because one or more lines are too long
											
										
									
								
							| 
						 | 
				
			
			@ -1161,29 +1161,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 />
 | 
			
		||||
| 
						 | 
				
			
			
 | 
			
		|||
		Loading…
	
		Reference in New Issue