...

DB를 호출하는 대부분의 병목 단일지점은 Aux라고 네이밍 지어진 장비...

REST 설계

기존 실시간 처리되는 저수준 패킷들을 모두 Rest화를 합니다.

...

기존 비동기 처리를 응답을 기다려야하는 Rest와 성능을 유지하면서 

설계를 해야할지가

...

고민이며 웹프레임워크의 튜닝요소를 깊게 살펴보는것에서부터 시작합니다.

URL : https://www.playframework.com/documentation/2.1.0/ThreadPools

로비처리 웹소켓 설계

실시간처리에 있어서 Rest는 적합하지 않으며 고성능 처리에 한계가 있습니다.

Rest호출 횟수를 줄이기위해 웹소켓을 보조적으로 사용을 하였습니다.

보통 동접3만 동접3만에 특정기능만 초당 천번이상의 Request가 필요한 정보다라고 측정이되면

이것을 RestAPI화 하여 DB를 호출하여 해결한다란것은 무모한젓입니다무모한짓입니다.

웹소켓으로의 전환이 필요하며 ,  일반적으로 처음 캐싱은 필수이며   처음 스냅샷데이터는 Rest로 처리하고,

이후 작은단위  지속적 갱신처리를 웹소켓화합니다작은단위 필요한 녀석만 지속적 갱신처리화도 필요한 부분입니다.

고성능 통신 라이브러리인 자바-네티를 사용하는 Atmosphere를 사용하였습니다.

고성능처리를 위해서는 여러가지 메시지기법과 같이 사용해야합니다.

URL : https://github.com/Atmosphere

...

3만명 가상 동접의 Load테스트 TPS 목표와 실제 측정 자료

측정 히스토리

클라이트가 아무 액션을 하지 않는 서버의 상태의 스냅샷을 기입합니다. 클라이언트가 아무 액션을 하지 않는다고

서버가 놀고있지는 않습니다. 사용자가 없이 흘러간 시간별 스냅샵 비교는 중요한 테스트 부분입니다.

기본적으로 백그라운드에서 작동하는 서비스가 있기때문에 0 - 1 액션의 Diff는 변화량을 측정하기가 어렵거나 미비합니다.

최소 100Action이상 사용자가 늘어나는 상황에서 비교를 하는게 의미 있는 데이터이나, 1액션 자체에 성능 문제가 있을수도 있기때문에

사소한것이라도 검증을 하는게 권장됩니다. 테스트 스크립트도 완성이되고, 1Node 테스트가 어느정도수행이되면 클러스터로

여러대를 구성하여 추가 테스트를 수행하게됩니다. 1Node 테스트때 찾지 못한 여러가지 문제를 찾게됩니다.

스케일아웃을 했다고 성능이 늘어났을것으로 기대하지만 예상외로 1Node일때 문제없는 성능부분이 스케일 아웃이되면서

예측하지 못한 많은 성능 문제가 발생하게됩니다. 오히려 병목지점을 예상하지 못하면, 단일지점 병목을 가속화시킵니다.

아무것도 하지 않는 서버의 상태측정

...

...

...

...

...

...

아무것도 하지 않는 서버의 상태측정은 중요한 내용입니다.

실제 로드테스트중 CPU가 틴다고 경고가 발생하여 그 문제를 찾느라 시간을 소비하였지만

최초 셋팅된 서버자체가 불필요한 서비스를 로드하면서 그냥 발생했던 문제였습니다.

...