고성능 네트워크 서버모델 서버엔진 개발기술..

최근 근황,
자체 서비스 목적용으로,
DuruBada (가칭) 서버,DuruBada ActiveX(추후 다른 기술로 대체),DuruBada Up/Down Controller Program
등등...웹하드 서버를 리눅스 에서 개발해야 한다.

전에 MS윈도우즈 플랫폼에서 메신저 만들던것은 MYSQL + 서버엔진은 IOCP + Thread Pool + DBPool 기술로 구현했었는데,
(쓰레드간 임계영역 동기화는 CriticalSection으로 구현함)

전에 UNIX 기반에서 공공기관에 개발해 납품했던 ocsmgr 메니저 서버는 동접이 약 1000명에 업무별 쓰레드 3-4개에서
poll 방식으로 구현 했던것이었고 금결원과 1대1 커넥션 서비스 납품했던 appc 데몬 서버도 역시 업무별 쓰레드 3~4개 로
accept 된 후 생성한 각 쓰레드내에서 select 하는 방식으로 클라이언트를 처리했고 또,청기와집 신원조회 같은 단순한 3 클라이언트가 최대 동접였던 경우는 쓰레드 없이 단순 fork 로 데몬을 구현했었다.

지금은 자체프로젝트인데,동접이 훨씬 많아야 하고,네트워크 처리량이 비교도 안될만큼 많은 플랫폼이고 리눅스 기반이다 보니,위와 같은 고전적인 단순한 방법으로 1 클라이언트당 1 쓰레드나 fork 로 클라이언트 접속을 해결하거나,
쓰레드 몇개 구동해서 (보다 발전적이면 접속을 accept 하기전에 쓰레드 풀로 미리 대기하고 있도록) ,각 쓰레드 별로 select 나 poll 등으로 IO 멀티플랙싱을 하는 방법도 있지만,이것은 고전적인 소켓모델이다. 여기서 RTS도 고려했지만,
RTS 보다도 10~20% 성능향상이 된 이벤트 기반 EPOLL(RTS와 함께 윈도우즈의 IOCP같은 이벤트기반 소켓 최신기술이라고볼수 있다) 로 구현한다.
단, 기존의 1 커넥션당 1 프로세스나 1 쓰레드 방식에서는 하나의 프로세스나 쓰레드가 은행 창구 처럼 1대1 고객응대 형태로 처음부터 끝까지 send,recv 를 반복하고 소켓 close 하고 끝나서 한텀에 클라이언트 업무를 처리했지만, 이렇게 되는 경우는, 업무가 분리되어 파일을 전송하고자 할때 클라이언트 접속이 되면 fopen() 하고 send/recv 하고 fclose 하고 소켓 close 하고 종료하면 되었던 단순한 로직이 다소 복잡하게 표현되어야만 한다.

즉,IO 이벤트 기반방식으로 하면 클라이언트 요청처리를 쓰레드마다 불특정하게 담당하므로 1스텝으로 해당 요청업무를 끝낼수 없는 구조가 되어 버린다.즉,은행창구처럼 시작부터 끝까지 한 프로세싱으로 처리가 되는것이 아니고,
여러 클라이언트의 요청을 번갈아 가면서 분산처리 된다고 볼수있다. 
이렇게 되면,각 Client 정보에 해당 fp 를 소유하고 있다가 현재 전송한 file pointer 부터 send 해줘야 한다.

DB 풀은 예를들어 10개를 미리 연결해 놓돼,각 쓰레드가 동시 접근되는 context-switch 이 되는 임계영역에 존재하므로,이 부분 역시 mutex로 잠금,해제 하여야 한다.
결론적인 고성능 서버개발 모델 스펙으로 채택한것은 EPOLL + 쓰레드풀 + DBPool 이고 mutex로 쓰레드간 임계영역 동기화 처리이다.

약 10일안에 개발해야 한다 ^^

개발서버 : http://durumul.iptime.org:8088 (개인용 서버이기 때문에 거의 열리지 않습니다)