[Perf] 전체 인덱싱 Queue 적체 및 DB Connection Pool Backpressure Benchmark 추가

[Gimini-3]

배경

기존 전체 인덱싱 처리량 Benchmark는 16·32개 문서의 Queue 지연과 처리량을 측정했지만, 동시 업로드와 Worker 실행 슬롯이 DB Connection Pool 용량을 넘어설 때의 대기와 포화 경계는 확인하지 못했습니다.

실제 PostgreSQL·MinIO·BGE-M3 전체 파이프라인에서 부하를 단계적으로 높여 Queue가 증가하는 양상, Hikari Pool 포화 및 Connection 대기, 처리량의 포화, 실패 또는 제한 시간 내 미완료가 처음 발생하는 지점을 재현 가능한 수치로 남깁니다.

범위

• 문서 수와 동시 업로드 수를 단계적으로 증가시키는 부하 프로필
• 고정된 Worker 실행 슬롯과 Hikari maximum-pool-size 기록
• 실제 업로드 → Job Queue → Parsing → BGE-M3 → vector 저장 → INDEXED 전환 실행
• Queue depth(PENDING/PROCESSING) 시계열과 peak/평균/AUC 측정
• Hikari active/idle/total/waiting 시계열과 최대 대기자·포화 시간 비율 측정
• 처리량, 업로드 지연, Queue drain 시간, 실패·미완료 수 측정
• 최초 Pool 포화·Backpressure·붕괴 관측 프로필 판정
• 전용 Gradle task와 실행·결과 문서 추가

판정 원칙

• Pool 포화: active connection이 maximum-pool-size에 도달
• Backpressure 관측: threadsAwaitingConnection이 1 이상 관측
• 붕괴 관측: 업로드 실패, Job 실패, 또는 제한 시간 내 Queue 미소진이 처음 발생
• 최대 부하에서도 붕괴하지 않으면 임의로 단정하지 않고 "측정 범위 내 미관측"으로 기록

완료 조건

• 일반 테스트와 분리된 전용 Benchmark task가 있다.
• 실제 인프라와 실제 BGE-M3로 단계별 부하를 실행한다.
• Queue와 Hikari Pool 상태를 별도 모니터링 연결로 샘플링한다.
• 각 부하 프로필의 처리량·Queue·Pool·실패 지표를 Markdown 표로 출력한다.
• Vector 1024차원, Chunk/Embedding 정합성, Job/Version 완료 상태를 검증한다.
• 실측 환경·명령·원시 결과·해석·한계를 docs/test-results에 기록한다.
• 제품의 요청 거절/Admission Control 정책은 이 이슈에서 새로 도입하지 않는다.

제외 범위

• 운영 환경의 보편적인 최대 처리량 단정
• API Rate Limit 또는 Queue Admission Control 구현
• PostgreSQL/OpenSQL 서버 자체 설정 튜닝
• Mock Embedding 기반 수치