perf: reduce tokio runtime thread limits

The Tauri backend is primarily the control plane for IPC, config generation, tray/window events, and mihomo API calls. The proxy data plane runs in the mihomo sidecar/service process, so allowing up to 16 runtime workers adds scheduling headroom without clear startup benefit.

Setup benchmark used isolated HOME/XDG dirs, isolated mihomo IPC sockets, sidecar mode, disabled TUN/system proxy defaults, and graceful shutdown after setup on an 18-thread host.

| limit | workers | blocking | setup async avg/max | avg threads |
| --- | ---: | ---: | ---: | ---: |
| old | 16 | 64 | 742.2ms / 1163.4ms | 34.5 |
| old | 8 | 32 | 650.8ms / 680.9ms | 27.0 |
| old | 4 | 16 | 681.5ms / 708.1ms | 23.8 |
| new | 16 | 32 | 682.8ms / 747.0ms | 35.3 |
| new | 8 | 16 | 650.1ms / 662.4ms | 26.0 |
| new | 4 | 8 | 639.3ms / 645.5ms | 22.1 |

The 2x blocking pool reduced tail latency across the tested limits. Capping workers at 8 keeps enough concurrency for normal control-plane work while avoiding the 16-worker tail-latency outlier and reducing blocking-pool headroom from 64 to 16 on this host.
This commit is contained in:
Tunglies
2026-05-25 17:24:06 +08:00
parent 2a397d7ef6
commit 8ccb0b9abd
+2 -2
View File
@@ -4,8 +4,8 @@ use std::sync::atomic::{AtomicUsize, Ordering};
fn main() {
let default_parallelism = std::thread::available_parallelism().map(|n| n.get()).unwrap_or(1);
let worker_limit = std::cmp::min(default_parallelism, 16);
let blocking_limit = 4 * worker_limit;
let worker_limit = std::cmp::min(default_parallelism, 8);
let blocking_limit = 2 * worker_limit;
#[allow(clippy::unwrap_used)]
let tokio_runtime = tokio::runtime::Builder::new_multi_thread()