Positive Mental Attitude

1. 소켓 이벤트 핸들링

IOCP > Overlapped Callback > select > WSAAyncSelect > WSAEventSelect

순서로 좋다고 합니다.

제 기억으로 2003년까지만 하더라도 IOCP 방식의 유용성에 대한 논란이 있었지만 이후 Windows 에서 대용량 서버를 만들 때 당연히 사용하는 방식이 되었습니다.

책에서 보니 1000명 이하에서는 select 방식도 성능이 괜찮았습니다. 1000명 이하의 접속을 처리할 때는 단순한 개발 및 멀티 플랫폼 대응을 위해 select 방식을 사용하는 것이 좋겠습니다.

WSAAyncSelect는 제 생각보다 성능이 좋지 않더군요. WSAEventSelect 보다 성능이 더 좋지 못하지만 WSAEventSelect는 성능도 괜찮고 사용 방법도 간편한데 접속이 64개밖에 되지 못하는 단점이 있습니다.

온라인 게임에서 클라이언트 측 소켓은 WSAEventSelect 방식을 사용하는 것이 좋겠습니다.

2. Accept 방식

AcceptEx + Pooling 이 제일 좋다고 합니다.

그렇지만 단순하게 접속 성능 테스트에서는 AcceptEx + No Pooling과 별 차이가 없지만 Pooling을 하면 Accept 부분을 빨리 처리할 수 있기 때문에 TimeOut 발생 확률을 줄일 수 있다고 합니다.

WSAAccept + Loop는 접속 처리 성능은 좋으나 동시 접속 수가 많을 때 TimeOut이 발생할 확률이 높다고 합니다.

3. 데이터베이스 인터페이스

작년까지만 하더라도 이 부분에서 제가 착각하고 있었던 것이 OLEDB가 ODBC 보다 빠를 것이라고 생각했는데 그렇지 않고 반대라는 것을 알게 되었습니다.

가볍고 속도를 중시할 때는 ODBC 방식이 좋고, ADO는 사용은 편하지만 성능상으로는 ODBC, OLEDB, ADO 중 가장 좋지 못합니다.

4. Nagle

수치적으로 No Nagle이 더 좋게 나오지만 사용하는 환경에 따라 꼭 좋다고만 할 수 없을 것 같습니다.

출처 : http://cafe.naver.com/jzsdn/16156

Nagle 알고리즘을 요약하자면 다음과 같다. 

 ACK가 빨리 올수록 데이터도 빨리 날아간다. 하지만 ACK가 바로바로 날아오지 않는 상황(즉 느린 WAN)에서는 알고리즘을 적용하지 않았을 때보다, 더 적은 수의 세그먼트들이 날아가게 된다. 즉 병목 현상을 줄이는 데 도움이 된다. 하지만 결국 데이터를 모아서 보내는 것이기 때문에 원래보다 반응이 느려진다. 빠른 반응이 필요한 애플리케이션의 경우, 이 알고리즘을 사용하지 않는 것이 도움이 될 수 있다.

 TCP_NODELAY 소켓 옵션을 이용해 알고리즘을 끌 수 있다.

출처 : http://www.serious-code.net/moin.cgi/TcpGlossary