Some more wording fixes too

@@ -0,0 +48,4 @@
+allow_incoming_typing = false
+```
+
+Presence is also considered expensive and is disabled by default. For reference, you can also disable them manually as follows:

@@ -0,0 +1,80 @@
+# Performance tuning
+
+While Continuwuity's default config parameters are optimized for a small instance, they would likely need additional modifications to smoothly run in a larger context. This is especially true for homeservers with many users and/or are joined in many large federated rooms, and will increasingly be the case as the Matrix network expands.

@@ -0,0 +19,4 @@
+## Changing database compression algorithm
+
+:::warning
+This step should be done **before** starting Continuwuity for the first time

@@ -0,0 +27,4 @@
+```toml
+### in continuwuity.toml ###
+rocksdb_compression_algo = "lz4"
+rocksdb_wal_compression = "none"

@@ -0,0 +5,4 @@
+This page aims to outline various performance tweaks for Continuwuity and their effects. As always, your mileage may vary according to your setup's specifics. If you have further discussions or recommendations, please share them in the community rooms.
+
+## DNS tuning (recommended)
+

@@ -0,0 +14,4 @@
+
+If you have unused memory to spare, consider increasing the `cache_capacity_modifier` value to a larger number, as to allow more data to be stored in hot memory. This would _significantly_ speed up many intensive operations such as state resolutions, and also results in decreased CPU usage and disk I/O. Start with a baseline of `cache_capacity_modifier = 2.0` and tune up until you find a satisfactory RAM usage.
+
+On the other hand, if your system doesn't have a lot of RAM, consider decreasing the cache capacity modifier to something smaller than `1.0` to avoid low-memory issues (at the cost of higher load on disk/CPU). The recommendation also works if your system has very few RAM compared to the number of cores, as cache capacities tend to scale according to the latter.

@@ -0,0 +28,4 @@
+allow_incoming_typing = false
+```
+
+Outgoing presence updates is also considered expensive and is disabled by default(`allow_local_presence = false`).

@@ -0,0 +10,4 @@
+
+## Cache capacities
+
+If you have unused memory to spare, consider increasing the `cache_capacity_modifier` value to a larger number, as to allow more data to be stored in hot memory. This would _**significantly**_ speed up many intensive operations such as state resolutions, and also results in decreased CPU usage and disk I/O. Start with a baseline of `cache_capacity_modifier = 2.0` and tune up until you find a satisfactory RAM usage.

@@ -0,0 +16,4 @@
+
+## Disabling some features
+
+You can disable outgoing **typing notifications** and **read markers** to reduce strain on the CPU and network.

@@ -0,0 +25,4 @@
+allow_outgoing_typing = false
+```
+
+Outgoing presence updates is also considered expensive and has been disabled by default(`allow_outgoing_presence = false`).

@@ -0,0 +102,4 @@
+
+### Using UNIX sockets
+
+If your homeserver and the reverse proxy lives on the same machine, you may consider exposing Continuwuity on a UNIX socket instead of a port. This would reduce TCP overhead between the two programs.

@@ -0,0 +143,4 @@
+
+### Serving .well-knowns manually
+
+Instead of [reverse proxying .well-knowns](./delegation#serving-with-a-reverse-proxy), you can serve them directly as manual files at the reverse proxy. This could decrease _some_ network request handling for Continuwuity.

@@ -0,0 +182,4 @@
+
+HTTP/3 support is mostly beneficial for faster Client-Server connections, especially in browser-based applications like Element or Cinny. Continuwuity includes experimental _outbound_ HTTP/3 support in its Docker images, so connections between Continuwuity servers can benefit from this too.
+
+### Increasing file descriptors

@@ -0,0 +1,183 @@
+# Performance tuning
+
+While Continuwuity's default config parameters are generally optimised, additional modifications can be made to better utilise your server resources. This is especially helpful for homeservers with many users and/or are joined in many large federated rooms, and will increasingly be the case as the Matrix network expands.

@@ -0,0 +10,4 @@
+
+## Cache capacities
+
+If you have unused memory to spare, consider increasing the `cache_capacity_modifier` value to a larger number, as to allow more data to be stored in hot memory. This *significantly* speed up many intensive operations such as state resolutions, and also results in decreased CPU usage and disk I/O. Start with a baseline of `cache_capacity_modifier = 2.0` and tune up until you find a satisfactory RAM usage.

@@ -0,0 +12,4 @@
+
+If you have unused memory to spare, consider increasing the `cache_capacity_modifier` value to a larger number, as to allow more data to be stored in hot memory. This *significantly* speed up many intensive operations such as state resolutions, and also results in decreased CPU usage and disk I/O. Start with a baseline of `cache_capacity_modifier = 2.0` and tune up until you find a satisfactory RAM usage.
+
+On the other hand, if your system doesn't have a lot of RAM, consider decreasing the cache capacity modifier to something smaller than `1.0` to avoid low-memory issues (at the cost of higher load on disk/CPU). The recommendation also works if your system has very little RAM compared to the number of CPU cores, as cache capacities tend to scale according to number of cores.

@@ -0,0 +60,4 @@
+
+### Changing the compression algorithm
+
+For reduced CPU usage at a tradeoff of increased storage space, consider deploying Continuwuity with the faster and less intensive `lz4` algorithm instead of `zstd` for rocksdb, and disable WAL compression entirely:

@@ -0,0 +68,4 @@
+rocksdb_wal_compression = "none"
+```
+
+The tweak can especially be helpful if you have an older or less performant CPU (e.g. a Raspberry Pi) and disk space to spare.

@@ -0,0 +72,4 @@
+
+### Increasing bottommost layer compression (`zstd` only)
+
+The bottommost layer of the database usually contains old and read-only data, and hence is a suitable place for further compression. In Continuwuity, this is possible by setting `rocksdb_bottommost_compression = true` and tuning `rocksdb_bottommost_compression_level` to a more compact level than the default one used in `rocksdb_compression_level`. The tweak comes at a cost of some increased CPU usage, but would prevent your database from growing too large especially in the long run.

@@ -0,0 +86,4 @@
+
+For `lz4` users, the default level (`-1`) is already the most compact. You can only further decrease it to favor compression speed over ratio.
+
+Consult these documentations for more information on compression tuning and levels:

@@ -0,0 +102,4 @@
+
+### Using UNIX sockets
+
+If your homeserver and reverse proxy lives on the same machine, you may wish to expose Continuwuity on a UNIX socket instead of a port. This reduces TCP overhead between the two programs.

@@ -0,0 +131,4 @@
+
+### Tuning your trusted servers
+
+Trusted servers are queried sequentially starting from the first entry of `trusted_servers`. If you have multiple notaries configured, put the faster ones first:

@@ -0,0 +137,4 @@
+trusted_servers = ["fastest.example.com","faster.example.com","matrix.org"]
+```
+
+Avoid using `matrix.org` as your primary notary, as it tends to be quite slow. If you need suggestions for trusted servers, ask in the Continuwuity main room.

@@ -0,0 +1,181 @@
+# Performance tuning
+
+This page aims to outline various performance tweaks for Continuwuity and their effects. These adjustments are especially helpful for homeservers that are in many large federated rooms or have many users, and it will become increasingly necessary as the Matrix network expands. As always, your mileage may vary according to your setup's specifics. If you have further discussions or recommendations, please share them in the community rooms.

@@ -0,0 +10,4 @@
+
+If you have unused memory to spare, consider increasing the `cache_capacity_modifier` value to a larger number to allow more data to be stored in hot memory. This *significantly* speed up many intensive operations (such as state resolutions) and decreases CPU usage and disk I/O. Start with a baseline of `cache_capacity_modifier = 2.0` and tune up until you are satisfied with RAM usage.
+
+On the other hand, if your system doesn't have a lot of RAM, consider decreasing the cache capacity modifier to something smaller than `1.0` to avoid low-memory issues (at the cost of higher load on disk/CPU). This recommendation also works if your system has very little RAM compared to the number of CPU cores, as cache capacities tend to scale according to number of cores.

@@ -0,0 +14,4 @@
+
+## Disabling some features
+
+You can disable outgoing **typing notifications** and **read markers** to reduce strain on the CPU and network.

@@ -0,0 +42,4 @@
+allow_outgoing_typing = false
+allow_incoming_typing = false
+
+# disabling presence updates entirely

@@ -0,0 +53,4 @@
+## Tuning database compression
+
+:::warning
+These steps MUST be done **before** starting Continuwuity for the first time, as database compressions are irreversible.

@@ -0,0 +100,4 @@
+
+### Using UNIX sockets
+
+If your homeserver and reverse proxy live on the same machine, you may wish to expose Continuwuity on a UNIX socket instead of a port. This reduces TCP overhead between the two programs.

@@ -0,0 +135,4 @@
+trusted_servers = ["fastest.example.com","faster.example.com","matrix.org"]
+```
+
+Avoid using `matrix.org` as your primary notary, as it tends to be quite slow. If you need suggestions for trusted servers, ask in the Continuwuity main room.

@@ -0,0 +178,4 @@
+
+Consider enabling the newer **HTTP/3** protocol for inbound connections to Continuwuity. In Caddy this is allowed by default, and you'd need to expose port :443/**udp** on your firewall.
+
+HTTP/3 support is mostly beneficial for faster Client-Server connections, especially in browser-based applications like Element or Cinny. Continuwuity includes experimental _outbound_ HTTP/3 support in its Docker images, so connections between Continuwuity servers can benefit from this too.

@@ -0,0 +8,4 @@
+
+## Cache capacities
+
+If you have unused memory to spare, consider increasing the `cache_capacity_modifier` value to a larger number to allow more data to be stored in hot memory. This *significantly* speed up many intensive operations (such as state resolutions) and decreases CPU usage and disk I/O. Start with a baseline of `cache_capacity_modifier = 2.0` and tune up until you are satisfied with RAM usage.

@@ -0,0 +128,4 @@
+
+### Enable HTTP/3 on your reverse proxy
+
+Consider enabling the newer **HTTP/3** protocol for inbound connections to Continuwuity. In Caddy HTTP/3 is allowed by default, and you'd need to expose port :443/**udp** on your firewall.