기본 콘텐츠로 건너뛰기

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 %에 가까워졌습니다. 특정 지점을 지나면 클라이언트는 지연되기 시작하고 서버의 부하가 감소합니다.

스크린샷


라벨:

댓글

댓글 쓰기

이 블로그의 인기 게시물

세상 간단한 https(+secured websocket): Caddy

nginx, apache2 같은 걸로 매번 certbot 연동을 통해 https 하는게 지겨워서 알아보니 Caddy라는게 있더라. 설치법은 강하게 크기 위해 알아서 해본다. # cat /etc/caddy/Caddyfile your.shitty.site:8123 {   proxy / localhost:9123 {     websocket     transparent   } } 이건 외부에서 8123으로 들어오는 걸 내부적으로 9123로 맞춰서 https 맞춰주는 reverse proxy. 만일 port를 생략하면 # cat /etc/caddy/Caddyfile your.shitty.site {   proxy / localhost:9123 {     websocket     transparent   } } 기본포트인 443으로 되어 https://your.shitty.site 로 접속이 된다. 요새 말썽이던 cloudflare 버리고 netlify domain이랑 caddy를 쓰니까 앓던 이가 빠진 느낌. 이 조합은 당분간 계속 써야겠다 싶다.
댓글 1개
자세한 내용 보기

LG G Pro 2 Custom Rom +Rooting 기록

선 루팅 https://forum.xda-developers.com/lg-g3/general/guide-root-lg-firmwares-kitkat-lollipop-t3056951 1.2버전 스크립트 모드로. echo Looking for LG serial port.. echo. adb.exe wait-for-device 여기에서 정체 상태여서 강제로 adb kill-server 했더니 알아서 재부팅하심. 폰에선 "펌웨어 업데이트"화면이 나오고 Phone found at COM5! Rooting phone.. If you don't see the SuperSu installer script runs within about a minute, then the root failed. Author : blog.lvu.kr SPECIAL COMMAND : ENTER, LEAVE ## 이런 상황이 됨. #이 느린 속도로 하나씩 증가하고 있음. 한 시간 기다려도 성과없음. 뭐 몇번해봐도 안되고 결국 불안하긴 하지만 kingroot.net  로 설치 롤리팝이니까  https://drive.google.com/file/d/0B4kfGU1z_PClQ3AyM2lKOGR1S3M/view  이걸 받아서 압축 풀기. d838recovery.bat 만 있어서 당황스럽긴한데 실행하고 1번 하니까 리커버리 모드 진입까진 잘 되는 듯. adb sideload 라는게 있어서 해봄. Advance에서 adb sideload 선택하고 USB연결한 PC에서 adb sideload RR-N-v5.8.5-20171010-d838-Final.zip 하니까 착착 잘 진행됨. 이제 흉측한 U+LTE 가 없어짐. ㅇㅋ 군더더기 없고 깔끔한데 남은 건 gapps 를 설치해야함. http://opengapps.org/  를 권해줘서 갔는데 지옥 느림. ARM + 7.1 + stock 이 기본이...
댓글 쓰기
자세한 내용 보기