티스토리 툴바


Long-Polling 방식과 Polling방식 선택하기
약간 번외로 웹채팅을 구현할 때 long-polling방식과 polling 방식 중 어느것이 효율적인가 장단점을 따져보도록 하겠습니다.

  • Long-Polling 방식을  선택해야 하는 경우
    • 약 3초 미만의 오차로 실시간 응답이 필요한 경우
    • 메신저 같이 1:1이나 약 10명 이하의 상대와 채팅하는 경우
    • 채팅 서버만 분리 할 수 있는 경우
    • ex) Facebook의 웹채팅, Google의 메신저, MSN의 웹메신저 등
       
  • Polling 방식을 선택해야 하는 경우
    • 응답이 실시간이 아니어도 괜찮거나 3초 이상의 시간차가 발생해도 무난한 경우
    • 약 10명 이상의 상대와 채팅해야 하는 경우
    • 다른 서버 어플리케이션과 함께 동작해야 하는 경우
    • ex) 전체 채팅이 필요한 웹게임이나 랜덤채팅 등


아시다시피 Long-Polling방식은 소켓처럼 거의 실시간으로 응답을 받게 할 수 있습니다.
 하지만 만약 100명이 전체 채팅하는 환경을 Long-Polling방식으로 구현한다면 어떻게 될까요?

Long-Polling 구조상 누군가가 말 한마디 하는 순간 100명의 유저가 동시에 응답을 받고, 다시 응답을 받기 위한 호출(Request)을 100명 모두가 동시에 하게 됩니다. 

순간적으로 Request Queue가 쌓이게 될테니 서버가 버벅대거나 심하면 뻗을 수도 있겠죠. (참고로 IIS의 Max Request Limits는 5000개 라고 하네요.) 

이런걸 self-DDOS라고 해야 하나요? ㅋ


하지만 아까 말했듯이 실시간 응답이 매우 중요한 요소이며, 종종 버벅대거나 뻗어도 상관없을정도로 채팅서버만 물리적으로 분리 해도 되는 환경이라면 Long-Polling도 괜찮은 선택이고,
그 외의 상황이라면 기본적으로 Polling방식의 채팅을 구현하는것이 안정적일 것 같습니다.


Performance Counter로 시스템을 감시해보시면 그 차이가 더욱 명확합니다.

Long-polling 방식은  유저들이 아무말도 안하고 있을땐 리소스를 거의 먹지 않다가, 누군가가 말하기 시작하면 카운터가 불규칙적으로 요동치기 시작합니다. 특히 누가 도배라도 한다면 난리납니다 ㅎㅎ

Polling 방식은 말 하든 안하든 주기적으로 새로고침 할 뿐이니까 일정주기별로 물결 그래프가 그려집니다.
아무래도 Polling방식이 다른 서버 어플리케이션과 함께 동작할 경우 오버헤드를 체크하기 훨씬 쉽겠죠. 하지만 유저가 아무것도 안해도 쓸데없이 리소스를 먹는다는게 아쉽구요.



하지만 Polling 방식으로 구현해도 혹시나 Server Request가 동시에 일어나게 되는 구조로 구현하신다면 Long-Polling의 단점을 그대로 안게 되므로 장점이 없어져 버립니다. 주의해서 개발하시길 바라며,
아무쪼록 웹채팅 구현하시는데 도움이 되셨으면 좋겠습니다. 이만~
저작자 표시 동일 조건 변경 허락
Posted by 귀뫄뉘
어제 간만에 MS 솔루션들을 몇개 써봤는데.. 

ASP.NET MVC3 
asp.net mvc3는 ... aspx와 같이 너무 쓸데없는 기능을 많이 넣었고 지나칠 정도로 jquery에 의존적으로 되버려서 깊이있게 튜닝하려 할수록 오히려 더 손이 많이 가는 계륵 같은 존재가 된것 같다.. 뭐 이건 MS쪽의 모든 개발솔루션의 특징이기도 하니 이제 그러려니 한다.. 개인적으론 MVC1이나 MVC2가 더 나은것 같다.

WebMatrix
그리고 간만에 또 사용해 본 WebMatrix는 매우 쉽고 훌륭했다.. 예전 asp정도의 개발능력만 있으면 될것같고, 트랜잭션이 필요없는 간단한 웹사이트 만들기엔 최고일것 같다. 
WebMatrix Tutorial Download(PDF) 

(2011/12/8 추가)
더 써보니 내가 개발자라서 그런지 아쉬운점이 많이 있긴 했다. 일단 Code Intellisense를 지원하지 않고 Syntax Highlighting만 지원한다. 기본 Database는 SQLCE(파일기반)인데, 다 좋은데 테이블 스키마의 필드네임을 수정할 수가 없다. 닷넷 개발자라면 솔직히 VS Web Express가 더 나을것 같았다. 다만 WebMatrix는 MS측에서 요즘 많이 신경쓰고 있는 php개발자 끌어안기를 위한 툴이라고 생각하면 나쁘지 않은것 같다.

nopCommerce 
그리구 WPI(Windows Platform Installer)를 오랜만에 실행시켜봤더니 웹어플리에이션 샘플이 많아졌다. Commerce항목중에 nopCommerce라는 솔루션 샘플을 봤는데... 헐.. 
그동안 쇼핑몰 제작 의뢰 받았던 대부분의 기능이 이미 구현되어 있고 그것도 매우 심플하게 구성되어 있었다.. 작은 쇼핑몰을 주로 만들어주는 소규모 SI라면 이거 Customizing해서 쓰는게 효율적일것 같다..

쇼핑몰 데모 : http://demo.nopcommerce.com/ 
관리자 데모 : http://admin-demo.nopcommerce.com/Admin 

 

[nopCommerce 관리자 대쉬보드 화면]
 

[nopCommerce 쇼핑몰 메인 화면]

저작자 표시 동일 조건 변경 허락
Posted by 귀뫄뉘
그동안 바빠서 오랜만에 포스팅 하네요. 이번엔 ASP.NET과  JQuery로 웹채팅을 구현해봤습니다. 
 이 채팅은 크게 Send부분과 Recv부분으로 나누어져 있습니다. 


명령어 전송 부분
Send부분은 단순히 POST방식으로 명령어(로그인/로그아웃/채팅/접속유저보기)를 보내면 성공실패 여부와 함께 해당 명령어의 응답데이터를 바로 받아보는 방식입니다. 즉 일반적인 웹페이지 호출방식입니다.

Send 부분



명령어 응답 부분
Recv부분은 GET방식으로 서버에 요청하면, 클라이언트로 보내줄 메세지가 생길때까지 대기하고, 메세지가 생기면 응답하고 응답을 받은 클라이언트가 다시 반복해서 서버로 요청하는 방식입니다. 이른바 Comet의 Long-Polling 방식입니다. (Comet에 관한 설명은 따로 검색해보시길..)

Recv 부분


Long-Polling, 즉 클라이언트가 응답받는 대기시간이 길어진다는 것은 서버 입장에서도 스레드가 많아진다는 단점이 있습니다. 이 문제를 보완하기 위해 서버쪽을 IHttpAsyncHandler로 구현했습니다.
IHttpAsyncHandler는 HttpHandler에서 비동기 처리를 지원합니다. (IHttpAsyncHandler에 관한 설명은 여기에..)


서버 구현하기
ASP.NET의 기술중에서도 WCF, WebService, Webform(MVC), HttpHandler 중에서 무엇을 써야할지 고민이 필요했습니다. 일단 최초선택은 WCF였습니다만... 좀 고전적인 방식(?)이 성능에 더 좋을것 같다는 근거없는 믿음에 근거(?)하여 HttpHandler로 구현하기로 했습니다.
사실 WCF의 장점은 JSON과 XML 직렬화가 간편하다는게 가장 강점이었는데, List나 Dictionary같은 Collection 객체가 Javascript나 Actionscript같은 클라이언트환경에서 편히 쓸수있는 구조로 직렬화가 되지 않아서 선택하지 않은 이유도 있었습니다.

메세지(명령어) 교환 포멧 
위에서 잠깐 얘기했듯이 XML포멧은 너무 데이터양이 많아서 제외했고, JSON포멧은 딱 좋긴한데 닷넷에서 JSON 직렬화 역직렬화가 너무 닷넷환경만 고려되어 있어 클라이언트쪽에서도 JSON포멧을 닷넷에 맞게 맞춰줘야 한다는게 단점이었습니다. 따라서 선택한게 역시 고전적인 방식(?)인 QueryString 방식을 택했습니다. 

클라이언트 구현하기
그냥 JQuery.


전체소스다운받기 



저작자 표시 동일 조건 변경 허락
Posted by 귀뫄뉘