diff options
| author | Christophe Besson <cbesson@gmail.com> | 2026-10-11 19:09:04 +0200 |
|---|---|---|
| committer | Christophe Besson <cbesson@gmail.com> | 2026-10-11 19:09:04 +0200 |
| commit | 176b5ed563f7022009b70751e62b7ee7901e6da0 (patch) | |
| tree | dfc3d3b4653cb63ef680cfd5d914fe52ba3a9635 /docs/USERGUIDE.md | |
| parent | aca58f66df5c21be71a7159620d0b50bb969199f (diff) | |
| download | meshbay-176b5ed563f7022009b70751e62b7ee7901e6da0.tar.gz | |
feat(node): carry connections on several cores
connection_processes (default 1) starts that many processes for the
WebRTC stack; sessions and keys stay in the node. Set from node.toml
or the Node page, applied to new connections.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Diffstat (limited to 'docs/USERGUIDE.md')
| -rw-r--r-- | docs/USERGUIDE.md | 7 |
1 files changed, 7 insertions, 0 deletions
diff --git a/docs/USERGUIDE.md b/docs/USERGUIDE.md index bc16ba6..5649b30 100644 --- a/docs/USERGUIDE.md +++ b/docs/USERGUIDE.md @@ -745,9 +745,16 @@ and running `meshbay-node reload`: | `max_concurrent_downloads` | 8 | node-wide download slots | | `max_concurrent_uploads` | 8 | node-wide upload slots | | `max_upload_gb` | 8 | the largest single file a member may send you | +| `connection_processes` | 1 | how many CPU cores carry members' connections | | `transcode_incompatible_video` | true | re-encode video no browser can play | | `hardware_video_encode` | true | use the GPU for that, if one actually works | +`connection_processes` is the one for speed. With 1, everything a node sends +goes through one core, about 35 MB/s shared between everyone downloading at +that moment. Raise it when several people download at once and the machine has +cores to spare: each one adds a core's worth, and about 85 MB of memory. It +applies to connections opened after the change. + `max_concurrent_streams` is the one to think about: a stream costs a video process for as long as the film lasts, so this counts **viewers**, not requests. |