<추가 - 2011년 8월 10일>
libev라는 비슷한 기능의 라이브러리가 있는데, libevent보다 나중에 만들어져서 libevent의 제한사항이나 버그를 해결했다고 하고, 성능도 libevent보다 조금 더 우수하며, API가 더 사용하기 쉽다고 한다. 그리고 libevent와 API과 호환이 되어서 기존에 libevent를 사용하도록 작성된 어플리케이션에서도 libev로 전환하기가 쉬운것 같다.
참고로 이 라이브러리는 멀티쓰레드 환경에서도 사용이 가능하다. 그리고 파일 디스크립터별로 타임아웃을 지정하는 기능이 있는데, 접속한 클라이언트 중에서 지정된 시간 이상 활동이 없는 것들을 찾아서 연결을 끊는데 유용하게 사용할 수 있다.
libevent를 사용해서 대용량 네트워크 서버 프로그램을 개발하는 방법에 대해서 여기를 참조한다. 참고로 이와 같이 Event-driven 방식으로 개발을 하면 적은 CPU/MEM 사용량으로 대량의 커넥션을 처리할 수 있지만, 실행 중에 코드의 일부분에서 블럭이 되면 서비스 전체가 멈춰버릴 위험성이 있다. 그래서 prefork된 다수의 쓰레드에서 각각 libevent를 사용해서 커넥션을 처리하도록 만들면 최악의 경우라도 해당 쓰레드에서 서비스하는 커넥션들만 문제가 생기도록 국한시킬 수 있고, 또한 멀티코어를 최대한 활용할 수 있도록 만들 수 있다.
그리고 부가적으로 Asynchronous DNS Resolution과 Simple Event-driven HTTP-Server도 제공한다.
자세한 내용은 libevent 웹사이트를 참조한다.
그리고 웹사이트에 보면 select, poll, kqueue, epoll의 성능을 비교한 결과가 있는데 select, poll은 디스크립터의 개수가 증가할수록 성능이 크게 저하되고, 둘 사이의 성능 차이는 거의 없는 것으로 나왔다. 반면에 kqueue, epoll은 디스크립터가 증가해도 성능 저하가 크지 않았고, 활성화된 디스크립터의 수가 많은 경우 kqueue가 약간 더 좋은 성능을 보여줬다.
사진 출처: http://www.monkey.org/~provos/libevent/
그리고 부가적으로 Asynchronous DNS Resolution과 Simple Event-driven HTTP-Server도 제공한다.
자세한 내용은 libevent 웹사이트를 참조한다.
그리고 웹사이트에 보면 select, poll, kqueue, epoll의 성능을 비교한 결과가 있는데 select, poll은 디스크립터의 개수가 증가할수록 성능이 크게 저하되고, 둘 사이의 성능 차이는 거의 없는 것으로 나왔다. 반면에 kqueue, epoll은 디스크립터가 증가해도 성능 저하가 크지 않았고, 활성화된 디스크립터의 수가 많은 경우 kqueue가 약간 더 좋은 성능을 보여줬다.
![]() | ![]() |
사진 출처: http://www.monkey.org/~provos/libevent/



comments
comments rss (+댓글 쓰러가기)