Per-Server Performance

Every server in the fleet carries its own performance envelope — set on the server’s edit screen, applied to that machine alone. The defaults are the tested configuration; these are the dials for when a box has a specific job or a specific limit.

Capacity and traffic

• Total clients — a hard ceiling on concurrent connections; the balancer respects it when placing viewers.
• Guaranteed speed — the bandwidth figure balancing weighs against demand.
• Rate limit and burst — requests per second per client, with a burst queue for the spikes players legitimately produce; the polite way to blunt aggressive clients without banning them.
• Gzip — compress the text responses (playlists, APIs) where CPU is cheaper than bandwidth.

The machine

• PHP services — how many worker pools serve requests; more on big hardware, fewer on a modest edge box.
• CPU governor — pin the machine to performance mode so clock speed never dips mid-stream.
• Custom sysctl — kernel overrides for this server on top of the standard tuning profile.
• RAM disk — segments are served from memory by default; the switch exists for the rare box where disk is deliberately preferred.
• Network interface and private IP — which NIC carries traffic, and an internal address for server-to-server transfers so viewer bandwidth stays clean.

A dedicated role

Timeshift only removes a server from live delivery entirely: it records and serves archive, nothing else. Pair it with big disks, point channels' archive settings at it, and the delivery fleet stays lean while catch-up scales on its own hardware.

Tune where the load actually is — the dashboard shows per-server CPU, memory and throughput, which is where every tuning decision should start.