연결 요청이 몰릴 때 listen backlog를 늘리면 서버 처리량도 늘어나나요?

backlog는 아직 수락되지 않은 연결을 기다리게 하는 큐와 관련된 설정이지 앱의 처리 능력을 늘리는 값은 아닙니다. OS의 연결 상태·큐 구분과 실제 상한을 확인해야 합니다.

동작 원리와 전제

SYN 처리와 완료된 연결의 accept 대기는 플랫폼별로 관리 방식과 지표가 다릅니다. accept 루프가 느리거나 파일 디스크립터·워커가 고갈되면 backlog만 늘려도 대기와 timeout이 커질 수 있습니다. 설정값과 커널이 적용한 한도가 다를 수 있습니다.

선택과 실패 처리

연결 수락을 빠르게 하고 무거운 처리를 분리하되 수락 후 큐도 제한합니다. 프록시·클라이언트 재시도가 새 연결 폭주를 만들지 않게 합니다. 정상 burst를 흡수할 여유와 지속 과부하를 거절하는 정책을 구분합니다.

구체적인 사례와 검증

초당 들어오는 연결이 accept와 실제 처리 능력보다 계속 많으면 큐를 키워도 결국 포화됩니다. 큐가 커진 만큼 사용자는 더 늦게 실패할 수 있습니다. 반면 짧은 순간 burst 뒤 부하가 내려오면 적절한 backlog가 정상 요청을 흡수하는 데 도움이 될 수 있습니다. 이 둘을 나누어 시험해야 합니다. accept 후 작업 큐가 무제한이면 커널 큐를 비우는 대신 앱 메모리가 고갈되므로 다음 계층에도 상한을 둡니다. connection timeout·재시도·로드밸런서 health가 같은 과부하를 어떻게 증폭하는지 관찰하고 수락 제한과 빠른 거절을 설계하겠습니다.

연결 생성률·accept 지연·큐 포화·거절·FD·요청 완료율을 함께 측정합니다. 부하를 내린 뒤 큐가 회복되는지 확인합니다. 대기열 크기를 키운 뒤 에러가 지연으로 바뀐 것을 처리량 개선이라고 보고하지 않겠습니다.