동시에 백 단위의 클라이언트에 개별적인 처리를 하는 정도라면 thread 정도로 충분합니다만, 일단 말씀하신 사항을 보니 Outbound bandwidth가 굉장히 크고 또한 Object의 사이즈와 수가 많기 때문에 네트워크 I/O 처리 모델보다는 캐시가 성능을 크게 좌우할 것이라고 생각됩니다. 이럴 경우 locking을 고려하다보면, 결국 select나 epoll 등과 non-blocking i/o 등을 사용하는 것이 좀 더 좋은 성능을 낼 수 있습니다.
(locking 해도 상관없다고 구현하기 더 편한 thread 모델을 사용하고 싶으실 수도 있지만, lock 종류가 많아지면서 역시 골치아파지죠...)
캐시가 성능을 크게 좌우할 것이라고 말씀드렸는데, 이 부분에 대해서는 정말 많은 고려가 필요할 것 같습니다. 간단한 캐시를 구현한답시고 Object를 통째로 메모리 캐시에 올려놓고 LRU로 replacement 하는 식으로 구현하시면, 동시에 수백~수천개의 Object를 클라이언트들에게 제공할 경우 제 성능을 발휘못하게 됩니다. 수많은 replacement로 인한 디스크 I/O가 병목이 되겠죠. Object 자체를 작은 Object단위로 나누고 메모리 캐시와 디스크 캐시를 동시에 활용하는 것을 고려해보시면 좋을것 같습니다.
kqueue, epoll, select 등에 대한 자료는 이 게시판에서만 검색해봐도 충분히 자료를 찾으실 수 있습니다.
그리고 말씀하신 서버와 가장 유사한 구조를 가진 것이 CDN 솔루션이나 웹캐시입니다. CDN 과 관련된 오픈소스 프로젝트가 있는지는 잘 모르겠습니다. 웹캐시의 경우는 처리하는 Object 사이즈가 매우 작기 때문에 다소 다른 성격이지만, 기본적으로 네트워크와 디스크 I/O 처리에 대하여 많은 도움을 얻을 수 있습니다. (웹캐시는 I/O 처리 빼면 시체입니다.) 오픈소스 프로젝트로 Squid 나 Oops Cache 등이 있으니 참고하세요.
댓글 없음:
댓글 쓰기