From 176b5ed563f7022009b70751e62b7ee7901e6da0 Mon Sep 17 00:00:00 2001 From: Christophe Besson Date: Sun, 11 Oct 2026 19:09:04 +0200 Subject: 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 --- docs/USERGUIDE.md | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'docs/USERGUIDE.md') 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. -- cgit v1.2.3