기본 콘텐츠로 건너뛰기

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

스크린샷


이 블로그의 인기 게시물

Mac 주의 - 약간 빡치는 git 대소문자 변환 파일명 변환(renaming)하는 법

Mac에서 종종 화나는 일 중 하나가 파일 시스템이 대소문자를 구분하지 않는 점이다.
가령, A.png를 a.png로 바꿔야할 경우 HFS 기준으론 전혀 바뀐 점이 없는 걸로 인식하는데 다소 화가난다.
하지만, 방법이 없는 것은 아닌데

A.png를 임의의 다른 파일로 바꾼다. (ex. A_.png)1에서 바꾼 상태에서 staging 한다. (git add A_.png)1의 파일을 다시 원래 바꾸려고 했던 파일로 바꾼다. (mv A_.png a.png)3을 다시 staging 한다. (git add a.png)commit 한다.https://stackoverflow.com/a/40307511/880991 에서 답변해준 Chris Barr 님에게 감사를.
* 추가

실제로 해보니 git mv --force A.png a.png 가 더 간단하다. 이는 바로 staging 영역에 add까지 해준다.

React-Native App 개발 시 Expo 선택 전에 고려해야할 것.

Expo는 지옥같은 React-Native 개발 환경 아래 섬광처럼 빛나는 훌륭한 도구지만 빛이 있으면 어둠이 있는 법.
https://docs.expo.io/versions/latest/introduction/why-not-expo.html 에선 이런 경우에 Expo를 사용을 고려하라고 전하고 있다.


독립형 앱에 이미지 같은 정적 자원(Assets)들을 함께 묶어 배포할 수 없다.background 혹은 장치가 잠자기 모드일때 코드 실행을 지원하지 않는다.일부 API를 미지원. Bluetooth, WebRTC 같은 건 아직.오버헤드가 꽤 크다. iOS 25MB, Android 20MBPush Notification의 경우 OneSignal 같은 외부서비스를 활용하려면 ExpoKit을 사용하거나 Expo가 아닌 React-Native를 사용해야한다.Staging/Production같은 다양한 디플로이 환경. 하지만 이 경우 https://github.com/oliverbenns/expo-deploy 같은 선택지도 있으니 참조할 것

즐거운 Online Prototyping Tool 들

jsbin, codepen, jsfiddle 이런 것들은 일단 생략. 너무 유명한 것들이라.

https://launchpad.graphql.com - node.js 기반 graphQL 연습장. 이것만으로도 충분히 훌륭한 백엔드
https://codesandbox.io/ npm 사용이 가능한 클라이언트 사이드 연습장. webpackbin이 너무 문제가 많아서 찾아본 것.

https://scrimba.com 이건 codesandbox+ asciinema(https://asciinema.org/) 같은 느낌인데 키 녹화와 음성 녹화 기능이 추가되었다. 다 좋은데 화살표 키로 빨리감기 뒤로감기 기능이 안되고 익스포트(youtube등)으로 지원이 없는게 아쉽다.

이 둘이 만나면? https://codesandbox.io/s/jvlrl98xw3?from-embed
뭐야 이거 무서워 하지마 ㄷㄷ;  graphql+react-native-web(부왘ㅋㅋ)

https://repl.it/languages 전통을 자랑하는 REPL 도구. 지원 언어 종류가 -_-;;;;;

https://tio.run/# repl.it? 장난함? 얘는 지원 언어가 무려 386종류. J랑 아희도 있다.

https://play.golang.org/ 즐거운 go playground. 소스 포멧팅 넘 좋아.

http://decaffeinate-project.org/repl/ 최고의 coffeescript REPL. 원래 용도는 coffee를 ecma6코드로 바꾸는 것이지만...

https://scaphold.io
https://www.graph.cool/ graphql backend service. scaphold.io는 설치도 필요없는 클라우드. graphcool은 호스팅+클라우드 다있음. 둘 다 막상막하. 푸쉬서버도 되고 뭐 미친득.

https://glitch.com/ gomix에서 결국 glitch로 안착.  node.js

https://www.shadertoy.com 잘하고 싶다! 쉐이다! 오디오도 된다!

http:/…