기본 콘텐츠로 건너뛰기

socketcluster tutorial - 11. 성능 (Performance)

성능


벤치 마크


처리량 (SocketCluster v0.9.8)


이 테스트의 목적은 SocketCluster가 적절한 머신에서 얼마나 많은 JavaScript (JSON) 객체를 처리할 수 있는지를 보는 것이었습니다.

절차

이 CPU 벤치 마크에서 SocketCluster는 Linux를 실행하는 8 코어 Amazon EC2 m3.2xlarge 인스턴스에서 테스트하였습니다.

  • 100 명의 동시 클라이언트가 있을 때까지 매 초마다 새로운 클라이언트를 생성하였습니다.
  • 전송한 최대 메시지 수는 170k (클라이언트 당 초당 1700 개의 메시지)로 설정하였습니다.
  • 메시지는 완전히 양방향이었습니다 - 클라이언트는 JSON으로 캐스팅 된 JavaScript 객체를 포함하는 'ping'이벤트를 보내고 서버는 'pong'JavaScript 객체로 응답합니다. 이 객체에는 현재 워커가 지금까지 받은 총 ping의 수를 나타내는 'count'속성이 있습니다.
  • SocketCluster는 5 개의 로드 밸런서, 5 명의 워커 및 2 명의 브로커를 사용하도록 설정하였습니다.

관측



  • 로드 밸런서 모듈을 v0.9.12로 업그레이드하면 워커 간에 훨씬 더 균등한 분배가 이루어졌습니다. 이전 버전의 loadbalancer는 갑작스러운 트래픽 급증에도 반응이 없었습니다. 새로운 버전의 loadbalancer는 무작위 확률을 결정론적 '불운'보정으로 활용하는 알고리즘을 사용하여 부하가 워커 간에 균등하게 분산되도록 합니다.
  • 프로세스 설정은 이전 벤치 마크에서 제대로 조정되지 않았습니다. CPU 코어보다 많은 프로세스를 사용하는 것은 낭비입니다.
  • 더 적은 수의 프로세스를 사용하여 매우 양호한 부하로 평균 3.33을 만들었습니다 (가능한 8 개 중). 아마도 우리의 현재 설정으로 20만 개의 접속이 되도록 했을 것입니다. 로드 밸런서 5대, 워커 5개, 브로커 2개가 여전히 이상적이진 않습니다. 아마도 한 명의 워커 프로세스가 완벽한 균형을 이루었을 것입니다.

스크린샷



동시성 (SocketCluster v0.9.20)


이 테스트의 목적은 SocketCluster가 얼마나 많은 동시 사용자를 처리할 수 ​​있는지 추정하는 것이었습니다.

절차


SocketCluster는 Linux를 실행하는 8 코어 Amazon EC2 m3.2xlarge 인스턴스에 배포되었습니다. SocketCluster 클라이언트는 Linux를 실행하는 최대 32 코어 Amazon EC2 c3.8xlarge 인스턴스에서 실행되었습니다. 이것은 단일 시스템에서 42K 동시 사용자를 시뮬레이트 할 수 있도록 하기 위해 필요했습니다.

  • 가상 사용자 (클라이언트)는 초당 약 160의 속도로 생성 (연결)되었습니다.
  • 동시 가상 사용자의 최대 수는 42K로 설정되었습니다. 이는 서버가 아닌 클라이언트의 한계입니다.
  • 각 가상 사용자는 평균 6 초마다 'ping'메시지를 보냈습니다. 'ping'이벤트의 페이로드는 JSON으로 변환한 JavaScript 객체였으며 응답은 지금까지 현재 워커가 받은 총 Ping의 수를 포함하는 'pong'객체였습니다.
  • 표준 브라우저 (Chrome)가 SC 서버에 원격으로 연결되어 (때때로 ping을 보내서) 전체 테스트에서 서비스가 실제 성능을 발휘하는지 확인합니다. 또한 시간이 지남에 따라 증가하는 ping 수를 확인하는 데 사용되었습니다.
  • SocketCluster는 4 개의 로드 밸런서, 3 명의 워커 및 1 개의 브로커를 실행하도록 설정하였습니다.

관측


  • CPU(가장 바쁜 워커)는 끝에 거의 60%까지 최고조에 달했고 새로운 연결은 여전히 ​​생성되었습니다 (초당 160 회).
  • 42K로 연결이 완료되면 가장 바쁜 워커의 CPU 사용이 약 45 %
  • 브로커는 많은 작업을 하지 않았습니다. 실제로 7 개의 CPU 코어만 완전히 활용되었습니다.
  • 로드 평균은 2 점 미만 (가능한 8 점)이었으므로 더 많은 사용자를 확보할 여지가 충분했습니다.
  • 메모리 사용량은 CPU 사용량과 비교할 때 무시할 정도였습니다.
  • huge 32-core EC2 클라이언트 시스템은 42K 연결을 훨씬 넘어서지 못했습니다. 클라이언트의 CPU 사용량은 모든 32 코어에서 100 %에 가까워졌습니다. 특정 지점을 지나면 클라이언트는 지연되기 시작하고 서버의 부하가 감소합니다.

스크린샷


라벨:

댓글

댓글 쓰기

이 블로그의 인기 게시물

cURL로 cookie를 다루는 법

http://stackoverflow.com/questions/22252226/passport-local-strategy-and-curl 레거시 소스를 보다보면 인증 관련해서 cookie를 사용하는 경우가 있는데 가령 REST 서버인 경우 curl -H "Content-Type: application/json" -X POST -d '{"email": "aaa@bbb.com", "pw": "cccc"}' "http://localhost/login" 이렇게 로그인이 성공이 했더라도 curl -H "Content-Type: application/json" -X GET -d '' "http://localhost/accounts/" 이런 식으로 했을 때 쿠키를 사용한다면 당연히 인증 오류가 날 것이다. curl의 --cookie-jar 와 --cookie 옵션을 사용해서 cookie를 저장하고 꺼내쓰자. 각각 옵션 뒤엔 저장하고 꺼내쓸 파일이름을 임의로 지정하면 된다. 위의 과정을 다시 수정해서 적용하면 curl -H --cookie-jar jarfile "Content-Type: application/json" -X POST -d '{"email": "aaa@bbb.com", "pw": "cccc"}' "http://localhost/login" curl -H --cookie jarfile "Content-Type: application/json" -X GET -d '' "http://localhost/accounts/" 이렇게 사용하면 ...
댓글 쓰기
자세한 내용 보기

MQTT 접속해제 - LWT(Last will and testament)

통신에서 중요하지만 구현이 까다로운 문제로 "상대방이 예상치 못한 상황으로 인하여 접속이 끊어졌을때"의 처리가 있다. 이것이 까다로운 이유는 상대방이 의도적으로 접속을 종료한 경우는 접속 종료 직전에 자신의 종료 여부를 알리고 나갈 수 있지만 프로그램 오류/네트웍 연결 강제 종료와 같은 의도치 않은 상황에선 자신의 종료를 알릴 수 있는 방법 자체가 없기 때문이다. 그래서 전통적 방식으로는 자신의 생존 여부를 계속 ping을 통해 서버가 물어보고 timeout 시간안에 pong이 안올 경우 서버에서 접속 종료를 인식하는 번거로운 방식을 취하는데 MQTT의 경우 subscribe 시점에서 자신이 접속 종료가 되었을 때 특정 topic으로 지정한 메시지를 보내도록 미리 설정할 수 있다. 이를 LWT(Last will and testament) 라고 한다. 선언을 먼저하고 브로커가 처리하게 하는 방식인 것이다. Last Will And Testament 라는 말 자체도 흥미롭다. 법률용어인데  http://www.investopedia.com/terms/l/last-will-and-testament.asp 대략 내가 죽으면 뒷산 xx평은 작은 아들에게 물려주고 어쩌고 하는 상속 문서 같은 내용이다. 즉, 내가 죽었을(연결이 끊어졌을) 때에 변호사(MQTT Broker - ex. mosquitto/mosca/rabbitMQ등)로 하여금 나의 유언(메시지)를 상속자(해당 토픽에 가입한 subscriber)에게 전달한다라는 의미가 된다. MQTT Client 가 있다면 한번 실습해보자. 여러가지가 있겠지만 다른 글에서처럼  https://www.npmjs.com/package/mqtt  을 사용하도록 한다. npm install mqtt --save 로 설치해도 되고 내 경우는 자주 사용하는 편이어서 npm install -g mqtt 로 전역설치를 했다. 호스트는 무료 제공하고 있는 test.mosquitto.o...
댓글 쓰기
자세한 내용 보기

OS X 터미널에서 tmux 사용시 pane 크기 조절

http://superuser.com/a/660072  글 참조. OS X 에서 tmux 사용시 나눠놓은 pane 크기 조정할 때 원래는 ctrl+b, ctrl+↑←→↓ 로 사이즈를 조정하는데 기본 터미널 키 입력이 조금 문제가 있다. 키 매핑을 다시 하자 Preferences(cmd+,) > Profile >  변경하고자 하는 Theme 선택 > Keyboards 로 들어가서 \033[1;5A \033[1;5B \033[1;5C \033[1;5D 를 순서대로 ↑↓→←순으로 매핑이 되도록 하면 된다. +를 누르고 Key에 해당 화살표키와 Modifier에 ctrl 선택 한 후 <esc>, [, 1, ;, 5 까지 한키 한키 입력 후 A,B,C,D를 써준다. 잘못 입력했을 땐 당황하지 말고 Delete on character 버튼을 눌러 수정하도록 하자. 그리고 다시 tmux에서 ctrl+b, ctrl+↑←→↓로 사이즈를 조절해보자. 잘 된다.
댓글 쓰기
자세한 내용 보기