IOCP 완료를 한 번에 많이 꺼내니 처리량은 늘었지만 짧은 요청이 늦어집니다. 배치 크기와 실행 예산을 어떻게 정하나요?

IOCP 완료를 한 번에 여러 개 꺼내면 GetQueuedCompletionStatus 호출과 큐 접근 횟수를 줄여 처리량을 높일 수 있습니다. 그러나 한 워커가 큰 배치를 독점하고 그 안의 무거운 완료를 오래 처리하면, 다른 연결에서 막 도착한 짧은 완료가 큐에 있어도 늦게 처리됩니다. 배치 크기는 클수록 좋은 값이 아니라 syscall 절감과 연결별 공정성, 사용자 p99를 함께 최적화하는 값입니다. 이 판단은 완료 배치의 공정성 문제입니다.

개수와 실행 시간을 분리합니다

GetQueuedCompletionStatusEx로 100개를 가져왔다는 것은 100개를 한 번에 사용자 작업까지 끝낸다는 뜻이 아닙니다. 완료 항목을 수집하는 예산과 각 항목의 프로토콜 파싱·복사·콜백·CPU 계산 예산을 따로 둘 수 있습니다. 네트워크 완료는 짧지만 특정 메시지가 압축 해제나 큰 JSON 처리로 무거울 수 있으므로, 한 워커가 가져온 배치의 뒤쪽 항목을 무기한 기다리게 하지 않겠습니다. 무거운 처리는 제한된 별도 실행기로 넘기되, 연결별 순서가 필요한 상태는 그 경계를 넘기면서도 직렬화해야 합니다.

큰 배치가 유리한 상황은 작은 완료가 많고 큐 접근 비용이 실제 병목이며, 연결 분포가 균일하고 처리 시간이 짧을 때입니다. 짧은 요청과 큰 작업이 섞이거나 특정 연결이 폭주하면 배치를 줄이고 시간 예산이 끝난 뒤 다시 포트로 돌아가 다른 완료가 선택될 기회를 줍니다. 큐가 한산한데 배치가 찰 때까지 기다리면 배치 이득보다 대기 지연이 커지므로 즉시 반환 기준도 둡니다. 항목별 오류·bytes transferred·OVERLAPPED 상태를 각각 해석해야 함수 전체 성공을 모든 I/O 성공으로 오해하지 않습니다.

실제 분포로 조정합니다

작은 메시지 중심, 큰 메시지 혼합, 특정 연결 burst, 많은 idle 연결 시나리오를 분리해 배치 크기와 실행 예산을 실험합니다. 초당 완료 수·CPU·syscall 수와 함께 연결별 p99, 가장 오래된 완료의 나이, 큐 체류 시간, 오류율을 기록합니다. 처리량이 증가해도 짧은 요청 p99가 SLO를 넘으면 배치 상한을 줄이거나 무거운 작업을 분리하겠습니다. 변경 뒤에는 순서·버퍼 수명·취소 경로가 유지되는지도 확인합니다.

IOCP에서 한 번에 100개 완료를 dequeue했다면 그 100개는 이미 포트 큐에서 빠진 상태입니다. 워커가 즉시 모두 처리하지 못한다면 자체의 bounded queue나 batch 보관 구조가 소유권을 유지해야 하며, ‘포트로 돌아간다’고 해서 미처리 항목이 원래 포트에 다시 남는 것은 아닙니다. OVERLAPPED와 버퍼는 해당 완료의 상태 처리가 끝날 때까지 살아 있어야 하고, 연결 종료와 queue 이동도 서로 경쟁하지 않게 해야 합니다.

작은 완료가 많은 균일 부하에서는 큰 batch가 syscall 비용을 줄일 수 있지만, 무거운 파싱·압축 작업이 섞이면 연결별 quota와 시간 예산이 필요합니다. 이미 꺼낸 batch를 오래 붙들지 않도록 자체 queue를 분할하되 연결별 순서가 필요한 상태는 직렬화하겠습니다. batch 크기 후보마다 초당 완료·CPU·syscall뿐 아니라 연결별 p99, 가장 오래된 완료 age, queue 체류와 오류·취소 처리를 비교하겠습니다.

이미 dequeue한 완료 항목은 포트가 다시 선택해 주지 않습니다. 워커가 모두 처리하지 못하면 자체 queue가 OVERLAPPED와 버퍼의 소유권을 보유하고, 종료 시 그 queue를 drain하거나 취소 계약에 따라 정리해야 합니다. ‘포트로 돌아간다’는 표현 대신 실제 재게시 여부와 소유권 이전을 명시하겠습니다.