joke-app/docs/reports/load-20261006.md

2차 부하·장애 주입 테스트 보고서 (2026-10-06, M9)

• 대상 커밋: 6cc3b75 (M9 합친 뒤: 다시 보기용 행동 시각 기록, 컴퓨터 상대 스케줄러, 체스 자체 수 생성기 포함)
• 환경·도구: 1차(load-20261004.md)와 같음. 봇 호스트(8코어, 30GB), 서버(MemoryMax 2G)·부하 생성기 각각 별도 systemd 스코프, localhost. scripts/loadtest.ts — 방마다 오목 선수 2 + 관전자 2, 방마다 2초에 한 수.

1. 기준 부하 (docs/10-testing.md §4)

항목	기준	1차(10-04)	2차(10-06)
동시 연결	2,000	2,000	2,000 (끝까지 유지)
진행 중 방	500	500	500
초당 행동	250	248.2	248.5
지연 p95	< 50ms	20.2ms	19.0ms
지연 p99	< 100ms	37.3ms	37.9ms
서버 CPU	< 70% (4코어 기준 2.8코어)	0.2코어	0.21코어
서버 메모리	< 1GB	141MB	163MB
오류·끊김	0	0	거절 0, 끊김 0

2. 장애 주입: 부하 중 서버 SIGKILL → 재시작

항목	결과
재연결	2,000/2,000 자동 재연결
저장된 수 유실	0
복구된 방	1,000 (진행 중 500 + 앞 측정에서 남은 방 500), 복구 실패 0
지연(전체 60초, 재시작 구간 포함)	p95 20.7 / p99 39.7ms
서버 오류 로그	0

3. 결론

• M9에서 늘어난 기능(행동마다 적용 시각 기록, 방마다 컴퓨터 상대 예약 확인)으로 성능이 나빠지지 않았다. 메모리만 22MB 늘었다.
• 기준 부하에서 서버 CPU가 0.21코어로 한도의 약 8%다. 방 단위 다중 프로세스 분산은 지금은 필요 없다. 다시 검토할 때: 동시 연결이 1만을 넘거나, 한 프로세스 CPU가 1코어를 꾸준히 넘을 때. 그때는 방 코드 해시로 프로세스를 나누고 앞단(Caddy)에서 /ws?room= 기준으로 보내는 방식부터 본다.

4. 재현 방법

1차 보고서 4절과 같다(PORT=4600 … LOADTEST_NO_HTTP_LIMITS=1 bun apps/server/src/index.ts, bun scripts/loadtest.ts --rooms 500 --spectators 2 --seconds 60 --pid <PID> [--chaos --restart-cmd …]).