mbs-panel/systemd/mbs-api.service

15 lines
308 B
SYSTEMD
Raw Permalink Normal View History

[Unit]
Description=MBS Panel — API + admin panel
After=network.target
[Service]
Type=simple
WorkingDirectory=/opt/mbs-panel
perf: multi-worker uvicorn + fix N+1 on the hottest path in the app mbs-api ran single-worker uvicorn with no --workers flag at all — one event loop handling every request. Now install.sh (and mbs update, so existing installs pick it up too) compute a worker count from nproc (clamped 1-4, matching typical VPS core counts) and bake it into the systemd unit via sed substitution of a __WORKERS__ placeholder. Safe to parallelize: verified no api.py module-level mutable state, all of it already goes through sqlite (payment idempotency and the xray-config file lock are already correct across separate processes, not just asyncio tasks within one — confirmed both are OS/db-level, not in-process). Verified with a mock dry-run of the new systemd-unit section (fake nproc, real sed substitution) producing the expected ExecStart line for several core counts. Also: build_subscription_text() — called on every single hit of /sub/{token}, the single most frequently called endpoint in the whole app, since every VPN client re-fetches on every reconnect — was doing one db.get_node() call per distinct node in a user's subscriptions instead of fetching once. Same N+1 shape as the admin-endpoint bugs fixed yesterday, except this one is on the hot path, not just the admin panel. Fixed to batch-fetch via db.list_nodes() once. Verified: correct output for a 4-node subscription (each node's address appears exactly once, de1's 4 transports all present, nothing silently dropped) and measured ~1.3ms/call average. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-12 16:13:44 +05:00
ExecStart=/opt/mbs-panel/venv/bin/uvicorn api:app --host 127.0.0.1 --port 8001 --workers __WORKERS__
Restart=on-failure
RestartSec=3
User=root
[Install]
WantedBy=multi-user.target