Performance
How Knight performs under load, measured on a normal VPS.
These figures come from a loopback stress test (1,000 simulated clients on one machine). They show engine overhead; real internet latency depends on network distance.
1,000 connected players
| Metric | Result |
|---|---|
| Players connected | 1000 / 1000 |
| Time to spawn (median) | ~5 ms |
| Time to spawn (95th percentile) | ~6 ms |
| Chat round-trip (median) | < 1 ms |
| Server memory | ~18–19 MB |
| Server CPU | ~2–4% |
Scaling
| Players | All spawned | Median spawn | Memory |
|---|---|---|---|
| 500 | 100% | ~5.6 ms | ~18 MB |
| 1000 | 100% | ~5.2 ms | ~18 MB |
| 1500 | 100% | ~5.5 ms | ~26 MB |
Tip
Knight keeps working well past typical SA-MP population sizes. Memory and CPU stay low because there is no Lua VM and no per-player scripting scheduler.
What affects performance
- Everyone sharing one core. Knight uses one thread for the tick loop, so a slow gamemode callback affects everyone.
- Database queries. Use the async variants (
sqlite_query_async,mysql_tquery) for slow queries. - Streaming distance. A very large
streamdistancesends more entity data per player. - Chat volume. Chat is broadcast to every connected player.