summary refs log tree commit diff
path: root/develop/usage/administration
diff options
context:
space:
mode:
authorerikjohnston <erikjohnston@users.noreply.github.com>2023-12-13 16:39:14 +0000
committererikjohnston <erikjohnston@users.noreply.github.com>2023-12-13 16:39:14 +0000
commit306ba25c38f864280c9f78a06816d713f1113416 (patch)
treecdde35d91cd432569b79e62878809fe7c0605aa3 /develop/usage/administration
parentdeploy: 0455c40085db7356f73b12e2592e35f02321c6ef (diff)
downloadsynapse-306ba25c38f864280c9f78a06816d713f1113416.tar.xz
deploy: 930dc9e2d3efd6d82b86c2205b80d6ccb9b4bb86
Diffstat (limited to 'develop/usage/administration')
-rw-r--r--develop/usage/administration/request_log.html2
-rw-r--r--develop/usage/administration/understanding_synapse_through_grafana_graphs.html6
2 files changed, 4 insertions, 4 deletions
diff --git a/develop/usage/administration/request_log.html b/develop/usage/administration/request_log.html
index e426f8a613..ca966d58ae 100644
--- a/develop/usage/administration/request_log.html
+++ b/develop/usage/administration/request_log.html
@@ -160,7 +160,7 @@
                         </div>
 
                         <h1 id="request-log-format"><a class="header" href="#request-log-format">Request log format</a></h1>
-<p>HTTP request logs are written by synapse (see <a href="https://github.com/element.-hq/synapse/tree/develop/synapse/http/site.py"><code>synapse/http/site.py</code></a> for details).</p>
+<p>HTTP request logs are written by synapse (see <a href="https://github.com/element-hq/synapse/tree/develop/synapse/http/site.py"><code>synapse/http/site.py</code></a> for details).</p>
 <p>See the following for how to decode the dense data available from the default logging configuration.</p>
 <pre><code>2020-10-01 12:00:00,000 - synapse.access.http.8008 - 311 - INFO - PUT-1000- 192.168.0.1 - 8008 - {another-matrix-server.com} Processed request: 0.100sec/-0.000sec (0.000sec, 0.000sec) (0.001sec/0.090sec/3) 11B !200 &quot;PUT /_matrix/federation/v1/send/1600000000000 HTTP/1.1&quot; &quot;Synapse/1.20.1&quot; [0 dbevts]
 -AAAAAAAAAAAAAAAAAAAAA-   -BBBBBBBBBBBBBBBBBBBBBB-   -C-   -DD-   -EEEEEE-  -FFFFFFFFF-   -GG-    -HHHHHHHHHHHHHHHHHHHHHHH-                     -IIIIII- -JJJJJJJ-  -KKKKKK-, -LLLLLL-  -MMMMMMM- -NNNNNN- O  -P- -QQ-  -RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR-   -SSSSSSSSSSSS-   -TTTTTT-
diff --git a/develop/usage/administration/understanding_synapse_through_grafana_graphs.html b/develop/usage/administration/understanding_synapse_through_grafana_graphs.html
index 051d85c464..11c85d56b1 100644
--- a/develop/usage/administration/understanding_synapse_through_grafana_graphs.html
+++ b/develop/usage/administration/understanding_synapse_through_grafana_graphs.html
@@ -163,11 +163,11 @@
 <p>It is possible to monitor much of the internal state of Synapse using <a href="https://prometheus.io">Prometheus</a>
 metrics and <a href="https://grafana.com/">Grafana</a>.
 A guide for configuring Synapse to provide metrics is available <a href="../../metrics-howto.html">here</a>
-and information on setting up Grafana is <a href="https://github.com/element.-hq/synapse/tree/master/contrib/grafana">here</a>.
+and information on setting up Grafana is <a href="https://github.com/element-hq/synapse/tree/master/contrib/grafana">here</a>.
 In this setup, Prometheus will periodically scrape the information Synapse provides and
 store a record of it over time. Grafana is then used as an interface to query and
 present this information through a series of pretty graphs.</p>
-<p>Once you have grafana set up, and assuming you're using <a href="https://github.com/element.-hq/synapse/blob/master/contrib/grafana/synapse.json">our grafana dashboard template</a>, look for the following graphs when debugging a slow/overloaded Synapse:</p>
+<p>Once you have grafana set up, and assuming you're using <a href="https://github.com/element-hq/synapse/blob/master/contrib/grafana/synapse.json">our grafana dashboard template</a>, look for the following graphs when debugging a slow/overloaded Synapse:</p>
 <h2 id="message-event-send-time"><a class="header" href="#message-event-send-time">Message Event Send Time</a></h2>
 <p><img src="https://user-images.githubusercontent.com/1342360/82239409-a1c8e900-9930-11ea-8081-e4614e0c63f4.png" alt="image" /></p>
 <p>This, along with the CPU and Memory graphs, is a good way to check the general health of your Synapse instance. It represents how long it takes for a user on your homeserver to send a message.</p>
@@ -194,7 +194,7 @@ present this information through a series of pretty graphs.</p>
 <p>This is quite a useful graph. It shows how many times Synapse attempts to retrieve a piece of data from a cache which the cache did not contain, thus resulting in a call to the database. We can see here that the <code>_get_joined_profile_from_event_id</code> cache is being requested a lot, and often the data we're after is not cached.</p>
 <p>Cross-referencing this with the Eviction Rate graph, which shows that entries are being evicted from <code>_get_joined_profile_from_event_id</code> quite often:</p>
 <p><img src="https://user-images.githubusercontent.com/1342360/82240766-de95df80-9932-11ea-8c15-5acfc57c48da.png" alt="image" /></p>
-<p>we should probably consider raising the size of that cache by raising its cache factor (a multiplier value for the size of an individual cache). Information on doing so is available <a href="https://github.com/element.-hq/synapse/blob/ee421e524478c1ad8d43741c27379499c2f6135c/docs/sample_config.yaml#L608-L642">here</a> (note that the configuration of individual cache factors through the configuration file is available in Synapse v1.14.0+, whereas doing so through environment variables has been supported for a very long time). Note that this will increase Synapse's overall memory usage.</p>
+<p>we should probably consider raising the size of that cache by raising its cache factor (a multiplier value for the size of an individual cache). Information on doing so is available <a href="https://github.com/element-hq/synapse/blob/ee421e524478c1ad8d43741c27379499c2f6135c/docs/sample_config.yaml#L608-L642">here</a> (note that the configuration of individual cache factors through the configuration file is available in Synapse v1.14.0+, whereas doing so through environment variables has been supported for a very long time). Note that this will increase Synapse's overall memory usage.</p>
 <h2 id="forward-extremities"><a class="header" href="#forward-extremities">Forward Extremities</a></h2>
 <p><img src="https://user-images.githubusercontent.com/1342360/82241440-13566680-9934-11ea-8b88-ba468db937ed.png" alt="image" /></p>
 <p>Forward extremities are the leaf events at the end of a DAG in a room, aka events that have no children. The more that exist in a room, the more <a href="https://spec.matrix.org/v1.1/server-server-api/#room-state-resolution">state resolution</a> that Synapse needs to perform (hint: it's an expensive operation). While Synapse has code to prevent too many of these existing at one time in a room, bugs can sometimes make them crop up again.</p>