얼마전에 libevent가 threadsafe 하지 않다는 글을 대충 번역 해서 올렸더니, 지인이 leader/follower pattern이라는 것을 소개 해줬다. 인터넷 검색 결과 ACE framework에서 사용 되는 서버패턴의 일종이라는데 아직 구현을 해보지 않아서 성능이 얼마나 나올는지는 장담하지 못한다.
내가 구현 하려고 했던 형식은 이벤트(accept/read ..etc)를 감시하는 thread가 하나 있고, 이벤트가 발생하면 event queue에 그 이벤트들을 집어 넣는다. 그럼 event queue 반대편의 worker thread들이 그 이벤트에 맞는 핸들링을 하는 구조 였는데 오버헤드가 많아서 실질적으로 사용하기는 다소 무리가 있는 형식이었다.
그에 반에 leader/follower pattern은 이벤트를 대기 하고 있는 leader thread, 아무것도 하지 않고 자신의 차례가 오길 기다리는 follower thread로 구성된다. leader thread가 이벤트를 대기 하다 이벤트가 발생하면 leader thread는 processing thread가 되어 event를 처리하러 가고, 대기 하고 있던 follower thread중에 하나가 leader가 된다. 그리고 processing thread가 제 할일을 다 끝내고 나면 다시 follower thread가 되어 자신의 차례가 올 때 까지 대기하게 된다.
지금 고민하고 있는 것은 follower thread들이 어디엔가 저장 되어 있어야 한다는 것이고, 내 생각에는 그런 자료구조로는 queue가 적당하지 않겠냐는 것이다. enqueue와 dequeue를 할 때 당연히 lock을 걸어줘야 할 것인데..그러면 이 것이 event queue를 운용할 때와 과연 얼마나 차이가 날까 하느냐 이다. 물론 event queue를 사용할 때는 하나의 이벤트가 발생할때 마다 이벤트 객체를 동적으로 생성 했기에 그에 대한 overhead가 있었을지 모르지만 그게 그렇게 크다고는 생각되지 않는다(잘 못 생각하는 것인가??).
이런 저런 것을 비교해 놓고, 이런 방법을 사용하면 이런면에 있어서 오버헤드가 줄어들기 때문에 성능이 월등히 좋아 진다..라는 문서라도 있으면 좋으련만..결국은 처음 부터 끝까지 구현해 보고 서버들을 벤치 마킹 하는 방법 밖에는 없을 것같다.
나중에 시간이 나면 one connection - one thread(가칭), event queue(가칭), leader/follower pattern을 서로 비교 해 보고 성능 평가 보고서를 한장 썼으면 한다.
참고 :
