크라우니집사회 v2.1 성능회귀 긴급수리
개요
deacon:9772 v2.1 배포 후 POST /api/council/mission 티켓 1개 생성이 26.5초 걸리고, 클라이언트(집사회.sh)는 --max-time 5 타임아웃으로 "[옴] 서버 무응답"을 오보고(서버는 실제로는 정상 처리 중이었음). 추가 실측에서 stats(10.78초)·claim(13.94초)·mission(8.25초, 컴파일 없는 MISS 경로)까지 전 경로가 느린 것으로 확인돼 범위가 확장됨.
무엇을 했는지
- RPN 사전판정 게이트 (
한선씨/명령변환.한선):가져오기가 있거나 소스가 8192바이트 초과면high2rpn.sh(RPN 변환+컴파일게이트, 실측 13.95초 걸리고 셀코어 임포트 코드에서는 매번 실패)를 아예 생략하고hanseonc_high직결. route 값 3+1종:RPN/HIGH_FALLBACK/HIGH_DIRECT(신규)/FAIL. - 미션장부 O(n²) 핫패스 수리 (
한선씨/미션장부.한선,한선씨/집사회.한선):_PSV파싱의 문자 단위글자()루프(O(L²), L=파일 전체 글자수)를분리()기반으로 교체(O(R×L)),_PSV파일유니크최신의 O(R²) id별 재스캔을 맵 기반 단일패스로 교체(O(R)), 통계/claim 핫루프의 행당 다중분리()호출을 1회로 통합,집사회.한선의 티켓 생성/claim/report가 이미 손에 쥔 행을 재활용해 재조회(재파싱) 없이 직접 기록하도록 리팩터. 규칙게이트.한선HIT 응답 비대화 발견 및 저장 시점 캡: brainq HIT 시 원본 소스 전체(수 KB)가결과요약에 그대로 저장되던 문제를 발견(라이브 T8·T9가 각 11.3KB).규칙게이트.한선자체는 범위 밖이라 손대지 않고,집사회.한선의_티켓생성_게이트시도에서 저장 직전 300자로 캡(_집사회_요약자르기).집사회.sh/집사회브릿지.한선타임아웃·오보고 수리: 쓰기 계열--max-time5→30초, curl rc=28(타임아웃)과 rc=7(연결거부)을 구분해 "응답 지연"과 "무응답"을 다른 문구로 출력.- 스펙 문서
집사회-스펙.md에 "v1.2 — 긴급 성능수리" 절 추가(실측치·근본원인·잔여 스케일링 이슈·후속 권고 전부 기록).
실측 결과 (테스트 포트 9776 사본, 라이브 9772 무접촉)
| 시나리오 | 수리 전(라이브 실측) | 수리 후(클린 데이터) | 수리 후(라이브 21행 스냅샷 그대로) |
|---|---|---|---|
| stats | 10.78초 | 0.024초 | 1.107초 |
| claim | 13.94초 | 0.021초 | 1.100초 |
| mission(MISS, 컴파일 없음) | 8.25초 | 0.792초 | 0.689초 |
| mission(HIGH_DIRECT, 셀코어 임포트) | 26.5초(구 RPN 시도 포함) | 1.35초 | — |
| mission(RPN 경로, 실제 재현) | — | 0.19초 | — |
100/500행 스케일링은 선형이 아님(정직 보고): 21→100행(4.8배)에서 17배, 100→500행(5배)에서 9.6배로 증가 — 분리()가 내부적으로 원본 전체 길이 기준 부분()을 호출하는 VM 비용모델 때문에 O(R×L)이 R에 대해 점근적으로 이차식. 진짜 O(n)을 하려면 VM 빌트인 비용모델을 바꾸거나 외부(awk/split) 위임이 필요 — 이번 수리 범위/시간 예산상 미시도, 스펙 문서에 후속 과제로 기록.
관련 파일
/Users/ef/crowny-deacon/한선씨/명령변환.한선(RPN 사전판정 게이트)/Users/ef/crowny-deacon/한선씨/미션장부.한선(_PSV파싱/_PSV파일유니크최신/통계문자열/대기티켓찾기/티켓상태갱신_행경유)/Users/ef/crowny-deacon/한선씨/집사회.한선(_티켓생성_게이트시도/클레임/보고/_집사회_요약자르기)/Users/ef/crowny-deacon/집사회-스펙.md(v1.2 절)/Users/ef/.claude/scripts/집사회.sh(타임아웃/오보고)/Users/ef/.claude/butler/집사회브릿지.한선(동일 판정 로직 한선씨 동반)
잔여 이슈
- 라이브
data/티켓.psv의 T8·T9 행(각 11.3KB) — 이번 수리는 더 이상 늘어나는 걸 막지만 기존 저장분은 그대로. 배포 시점에 수동 정리 권장(작은 장부라 안전). - 100/500행 스케일링 비선형 — 컴팩션(최신행만 남기기) 기능 추가 또는 VM 빌트인 비용모델 우회(외부 split)가 근본 해법. 이번 수리에서 미시도.
- 라이브 배포는 메인 세션이 수행(이 작업은 무접촉 원칙 준수,
/tmp/deacon-perftest사본에서만 검증).