perf(server): hold 20 TPS at 50-player scale

This commit is contained in:
itsRevela
2026-04-25 13:42:29 -05:00
parent 18a08ec693
commit ce9ffefba6
11 changed files with 487 additions and 32 deletions

View File

@@ -0,0 +1,29 @@
@echo off
REM FourKit steady-state TPS validation: 50 concurrent moving bots that stay
REM connected for the full duration with NO disconnect/reconnect rotation. The
REM "real workload" complement to test_fourkit_chunk.bat. Isolates steady-state
REM per-tick cost from the mass-disconnect cleanup spikes that bot rotation
REM triggers. Validates that chunk-send throttles hold 20 TPS at scale once
REM the initial scatter chunk-load wave has drained.
REM
REM Suggested in-game routine while this is running:
REM 1. Wait ~10s for bots to fully join.
REM 2. Run /fktest scatter to spread them across the world.
REM 3. Wait ~30-60s for chunk-load wave to drain.
REM 4. Run /fktest tps and read the 5s/30s/60s windows.
REM
REM Set require-secure-client=false in server.properties before running. The
REM 100-tick cipher handshake grace cannot keep up with 50 simultaneous bot
REM joins, which is unrelated to what this test is measuring.
set /p HOST="Server IP [127.0.0.1]: " || set HOST=127.0.0.1
set /p PORT="Server Port [25565]: " || set PORT=25565
if "%HOST%"=="" set HOST=127.0.0.1
if "%PORT%"=="" set PORT=25565
REM --hold 99999 99999 : bots never reach the hold timeout during the run, so
REM they stay connected for the full duration.
REM --cycles 0 : the spawner keeps launching until --bots is reached.
REM (cycles is a global spawn counter, NOT a per-bot
REM reconnect cap; cycles=1 would cap total spawns at 1.)
REM --duration 600 : 10-minute run; cap at whatever you need
python "%~dp0stress_test.py" %HOST% %PORT% --bots 50 --burst 10 --move --hold 99999 99999 --ramp 0.5 --duration 600 --cycles 0 --quiet
pause