인프라·운영 추정

초당 100건이면 평균 동시 처리는 몇 건인가요?

사용할 도구

초당 100요청에 실행 슬롯 100개가 필요할까요? 체류 시간에 따라 다릅니다. 0.01초 작업과 2초 기다리는 작업은 같은 도착률이라도 동시에 남은 수가 다릅니다. 도구는 안정된 시스템의 평균을 연결할 뿐 서버 대수를 자동 결정하지 않습니다.

단위를 포함한 첫 계산

L = λ × W
100 requests/second × 0.2 seconds = 20 requests

평균 동시 수 모드에서 도착률 100·평균 체류 0.2초는 20입니다. 초가 약분되어 요청 수가 됩니다. 사용자나 CPU 수가 아니므로 무엇을 한 요청으로 세고 어떤 시스템 경계 안인지 정하세요.

200ms는 0.2초로 넣습니다. 200이면 200초로 읽어 20000이 되어 천 배입니다. 분당 100건도 초당 100건과 다릅니다. 단위 실수를 성능 문제로 보지 않도록 식과 단위를 남기세요.

접수부터 응답까지라면 큐와 외부 응답 대기도 체류에 포함됩니다. CPU 사용 시간만 넣으면 다른 질문입니다. 전체 API 도착률과 DB 구간 시간만 섞지 말고 같은 대상이 같은 경계를 드나드는 비율과 시간을 쓰세요.

0.2초 중 0.15초가 외부 대기라면 20건 체류가 CPU 20개 상시 사용을 뜻하지 않습니다. 비동기와 연결 처리에 따라 자원 사용이 다릅니다. 체류 건수와 CPU 시간·연결 풀 산정을 분리하세요.

시간만 바꾼 비교

100/s × 0.2 s = 20
100/s × 0.5 s = 50
100/s × 2.0 s = 200

100을 유지하고 시간을 0.5·2초로 바꾸면 50·200입니다. 도착 급증 없이 완료 지연만으로 동시 수가 늘 수 있습니다. 식은 관계를 설명할 뿐 지연 원인을 진단하지 않으니 시간 내역은 관측으로 확인하세요.

같은 도착률에서 평균 체류가 줄면 평균 수가 줄어듭니다. 가장 빠른 요청만 개선됐다면 평균 입력을 바꿀 근거는 아닙니다. 전후 같은 요청 집단과 집계 방식을 비교하세요.

버스트와 긴 요청은 순간 수를 평균보다 높입니다. 평균 20이 한도 20이면 대기 없다는 보장은 아닙니다. 도착률에 p95·p99 시간을 곱해 같은 분위의 동시 수라고 부를 수도 없습니다. 평균 사이의 관계입니다.

올림 참고값도 자원 수 보장은 아닙니다. 평균 0.5는 빈 시간까지 포함한 값이지 물리적 반 요청이 아닙니다. 용량에는 허용 대기·피크·실패·부하 시험 같은 추가 조건이 필요합니다.

도구는 평균적으로 안정된 시스템을 전제합니다. 잔량이 계속 늘어나는 구간을 지속 가능한 정상 상태로 해석하지 마세요. 초기 잔량·실패·취소·관측 경계를 넘는 긴 요청이 집계에 영향을 줍니다. 비교 가능한 구간의 도착과 완료를 확인하세요.

초당 100건·접수부터 응답까지 평균 0.2초·평균 체류 20건처럼 입력과 경계를 함께 적으세요. CPU나 최대 연결 수 대신이 아니라 대기 증가 설명과 측정 불일치 발견에 쓰면 실무와 연결됩니다.