epoll로 채팅서버를 제작하고 있습니다.
동접자 5-6000명 이상으로 생각하고 있는데요..
epoll을 이용하려 하는데
accept나 receive 하는 곳에는 '
쓰레드를 이용하여야 하나요 ?
accept는 떼어놓고 cpu가 두개 이상거나 지연이 발생하는 I/O가 있다면 Thread로 아니면 하나로 하면 좋을듯한데 경험이 없어서리... 확실한 답변을 못드리겠군요.
어째든 thread 5000개 만들 생각은 하지 마시길 ^^; 수천개의 thread를 띄워서 도는 상용 server도 봤음 많이 웃었음:) 대략 황당 :( 잘돌아 간다고 이야기함 서버 비싸겠다 ㅎㅎ)
쓰레드를 사용하지 않아도 됩니다.
non-blocking socket으로 소켓을 바꾸고 read, send등을 호출해 주시면 됩니다. 처리할 로직이 간단한 경우 single thread로 event driven 모델에 따라 프로그래밍 해 주시면 퍼포먼스가 좋은 서버를 만들어 내실 수 있습니다.
쓰레드를 꼭 써야 할 경우는
1. 로직 처리 도중에 blocking I/O를 한다. 예를 들어 로직 처리 중에 fread 같은 걸 호출하신다면 그거 하나 처리하느라 다른 request는 전부 대기해야 겠죠.. 이 경우 멀티 쓰래드는 필수입니다.
2. 평균적인 반응 속도가 중요하다. 멀티 쓰레드로 프로그래밍을 하면 평균적인 응답속도가 올라갑니다. 특히나 처리 로직이 아주 길다거나 하면 멀티 쓰래드 전략도 유용하겠죠..
3. 머신이 좋다. 씨피유를 너댓개 쓰신다면.. SMP의 이점을 충분히 누릴 수 있는 멀티 쓰레딩 쪽이 좋습니다. 뭐, 싱글 쓰래드로 짜고 서버를 너댓개 띄우셔도 되겠습니다만. ^^
사실 멀티 쓰래드를 사용하셔도 성능은 충분히 나옵니다. 개인적으로는 event-driven 모델을 선호합니다만 멀티 쓰레드 모델이 더 낫다고 말하는 견해도 있습니다.
http://www.usenix.org/events/hotos03/tech/full_papers/vonbehren/vonbehren_html/
위 논문도 참조해 보시구요.. 십만개의 유저레벨 쓰래드로 웹 서버를 만들어 좋은 퍼포먼스를 얻어냈다는 논거도 포함되어 있습니다. 쓰래드를 사용하면 생각의 흐름대로 프로그래밍 하기 좋은 반면, 데이터를 보호하는 일이 좀 골치아파 지죠. 이벤트 드리븐은 state를 관리해야 하는 오버해드가 있고요.. 사실 좀 덜 직관적이기는 합니다. :)
괜히 웃었군요... :shock: 10만개의 쓰레드방식도 퍼포먼스가 괜찮게 나는군요. overhead가 심할거라고 생각해는데.
텍스트 포맷에 대한 자세한 정보
<code>
<blockcode>
<apache>
<applescript>
<autoconf>
<awk>
<bash>
<c>
<cpp>
<css>
<diff>
<drupal5>
<drupal6>
<gdb>
<html>
<html5>
<java>
<javascript>
<ldif>
<lua>
<make>
<mysql>
<perl>
<perl6>
<php>
<pgsql>
<proftpd>
<python>
<reg>
<spec>
<ruby>
<foo>
[foo]
accept는 떼어놓고cpu가 두개 이상거나 지연이 발생하는 I/O가
accept는 떼어놓고
cpu가 두개 이상거나 지연이 발생하는 I/O가 있다면 Thread로
아니면 하나로 하면 좋을듯한데 경험이 없어서리...
확실한 답변을 못드리겠군요.
어째든 thread 5000개 만들 생각은 하지 마시길 ^^;
수천개의 thread를 띄워서 도는 상용 server도 봤음 많이 웃었음:)
대략 황당 :( 잘돌아 간다고 이야기함 서버 비싸겠다 ㅎㅎ)
쓰레드를 사용하지 않아도 됩니다. non-blocking sock
쓰레드를 사용하지 않아도 됩니다.
non-blocking socket으로 소켓을 바꾸고 read, send등을 호출해 주시면 됩니다. 처리할 로직이 간단한 경우 single thread로 event driven 모델에 따라 프로그래밍 해 주시면 퍼포먼스가 좋은 서버를 만들어 내실 수 있습니다.
쓰레드를 꼭 써야 할 경우는
1. 로직 처리 도중에 blocking I/O를 한다. 예를 들어 로직 처리 중에 fread 같은 걸 호출하신다면 그거 하나 처리하느라 다른 request는 전부 대기해야 겠죠.. 이 경우 멀티 쓰래드는 필수입니다.
2. 평균적인 반응 속도가 중요하다. 멀티 쓰레드로 프로그래밍을 하면 평균적인 응답속도가 올라갑니다. 특히나 처리 로직이 아주 길다거나 하면 멀티 쓰래드 전략도 유용하겠죠..
3. 머신이 좋다. 씨피유를 너댓개 쓰신다면.. SMP의 이점을 충분히 누릴 수 있는 멀티 쓰레딩 쪽이 좋습니다. 뭐, 싱글 쓰래드로 짜고 서버를 너댓개 띄우셔도 되겠습니다만. ^^
사실 멀티 쓰래드를 사용하셔도 성능은 충분히 나옵니다. 개인적으로는 event-driven 모델을 선호합니다만 멀티 쓰레드 모델이 더 낫다고 말하는 견해도 있습니다.
http://www.usenix.org/events/hotos03/tech/full_papers/vonbehren/vonbehren_html/
위 논문도 참조해 보시구요.. 십만개의 유저레벨 쓰래드로 웹 서버를 만들어 좋은 퍼포먼스를 얻어냈다는 논거도 포함되어 있습니다. 쓰래드를 사용하면 생각의 흐름대로 프로그래밍 하기 좋은 반면, 데이터를 보호하는 일이 좀 골치아파 지죠. 이벤트 드리븐은 state를 관리해야 하는 오버해드가 있고요.. 사실 좀 덜 직관적이기는 합니다. :)
괜히 웃었군요... :shock:10만개의 쓰레드방식도 퍼포먼스가 괜
괜히 웃었군요... :shock:
10만개의 쓰레드방식도 퍼포먼스가 괜찮게 나는군요.
overhead가 심할거라고 생각해는데.
댓글 달기