...

테스트 스크립트도 완성이되고, 1Node 테스트가 어느정도수행이되면 클러스터로 여러대를 구성하여 추가 테스트를 수행하게됩니다. 1Node 테스트때 찾지 못한 여러가지 문제를 찾게됩니다. 스케일아웃을 했다고 성능이 늘어났을것으로 기대하지만 예상외로 1Node일때 문제없는 성능부분이 스케일 아웃이되면서 예측하지 못한 많은 성능 문제가 발생하게됩니다.

Test	DOC	Note
Object Trace Test at 1 Action	측정자료	1액션당 변화량 측정
Object Trace Test at NoAction	측정자료	AKKA/Atmosphere/Our Class Object 비활동 베이스 변화량 측정
Object Trace Test at NoAction in chatServer	Image Modified	아무 활동 안하는 Chat 서버의 메모리 변화량이 비정상으로 보임,일반적 GC 활동으로 잠정 결론
MemUsage	측정자료	Total/.net/JavaHeap/JavaPermgen/Unused+unknown(JNI)
Diff Dump	측정자료	test Lobby API in a simple scenario (send a few requests), make 3 memory dumps (before/during/after) and check Retained memory
Trace Thread	Image Modified	Lobby API 에서 Topic 관련 쓰레드가 , 비활동중임에도 불구하고 Running 상태가 반복됨 ( 정상적인 쓰레드 활동인지 체크해야함),해결반안 ActorSystem을 다중으로 사용하지말고, Event Bus로 전환 , AKKA의 오브젝트가 많아 진것도 이로인한 디펙인듯 보임
SSL vs None SSL	–	SSL의 최초 커넥션타임이 길고,약간의 메모리증가 무시할수 있는수준의 약간의 메모리증가
JNI Call Test	JNI 는 충분히 빠름 : Lock블락이 포함된 C# 코드를 jni를 통해 5000번 콜한게 20ms이내에 완료됨	logger.debug( “PerformTestJNI ProcessedTime: ” + Long.toString(processTime) )

성능 개선을 위한 기타 정보

가비지 컬렉트가 없는 C++에서는 메모리 해제, 큐를 통한 효율적 메모리 관련,메모리 재사용등이 성능향샹에

...

메모리를 효율적으로 누수없이 잘사용하는것은 개발 초기 단계에서부터 실수하지 않도록 고려해야하는 부분입니다.

성능 개선을 위한, 로직 개선전략

커넥션을 미리준비
중계 API 는 중계 서비스로, DB SP에대한 어떠한 콜도 하지 않습니다.  여기에서 필요로하는 모든 데이터는
서비스 SERVER로부터 받게되며 서비스 SERVER 로 해당 기능 요청을 위임하게 됩니다. 이때
서비스 SERVER로의 커넥션이 필요하게 되며  RESTFUL 요청시마다 커넥션이 발생하면 커넥션 오버헤드가 발생하기때문에
SOCKET QUEUE 를 미리 준비하여 (20개)  , 재사용하며  이때 발생하는 커넥션 타임을 0인 상태로 작동을 하게합니다.
 
모드분리
SOCKET QUEUE가 존재하지만, 모든 요청에대해 커넥션이 필요한것은 아니며, 커넥션이 필요없으면
필요없는 채로 작동되게 됩니다.

중계 API는 성능 향상및 커넥션수를 최적화하기 위해  다음과 같이 3가지 모드가 있습니다.
 
1.Share Mode

관련 api: GET SomeInfoList BY FILTER,GET SomeInfoList BY ID
공용으로 사용되는 정보 리스트의 경우, 리스트 동기화부터 모든 데이터를
모든 유져가 공용으로 사용할수 있으며, 이때 필요한 서버 커넥션 수는 유져수와
상관없이 , 1개만 있으면 됩니다.
 
2.Login Mode
관련 api : SomeBUY, SomeEGISTRATION,Some UNREGISTRATION
로그인 모드일시, AuthToken이 필수적으로 필요하며, 자기 자신에대한 처리가 필요함으로 서버 커넥션수는  유져수(AuthToken 발급수) 와 동일합니다.
 
3.Guest Mode
관련 api: SomeInfomation,SomeSTATE,SomeLEADERBOARD
요청 타임시 갱신된 정보를 받아야할 필요가 있을시, 로그인 없이 준비된 커넥션 풀링 에의해 ( 커넥셕수 지정가능-현재 5개 ) 최신 정보를 획득할수 있게 됩니다.
 
 
기존 서버에 완료 신호 추가
기존 다운로드 클라이언트의 경우, 모든 기능에대해 실시간 통신을 하고 있으며 어떠한 요청에대해 비동기적으로 작동중입니다.
하지만 RestFul의 경우 해당 데이터에대한 처리 완료를 필수로 해야하며,  기존 서버의 처리 경우 데이터가 존재하지 않을시 아무런 반응이 없기때문에 중계 API는 어느시점까지 대기할지 알수가 없으며 지정된 타임아웃이 발생합니다.
이경우, 해당 데이터가 없으니 대기를 멈추어라는 신호를 기존 서버에 추가할수가 있습니다. (PK_SOMEAPI_STOP_SYNCWAIT)
타임아웃 발생률을 감소 시켜서  LOBBY API 성능향상이 약간 기대가 됩니다.

...

string builder 테스트 Json 차이보기 캐스팅 성능이슈

프로파일 툴

부하 테스트시, 문제를 분석하고 찾을수 있는 프로파일 툴의 사용법을 익힙니다.. 불가피 하게 실서비스에서만 발생하는 문제를 찾기위한 Remote로 확인하는 방법까지 사용법을 익혀둡니다.

...

• 테스트 사이트 설정시 서비스 장비와 동일한 개수가 이상적이나, 상황에 맞게 목표타켓을 맞춰줍니다.

• 실 사용자 계정을 복사하여 테스트는 대부분의 사이트가 불가하며, 활성화 유져수에 해당하는 가상유져및 가상네트워크를 사용하는 전략을 세웁니다.

• 결제와 같은 API는 테스트가 불가할수 있습니다. 그러면 결제 API와 유사한 반응속도와 작동을 하는 더미 API 개발이 필요할수 있습니다.

• API를 통해 DB성능 테스트가 자연스레 포함되기때문에, 서비스 DB의 데이터량(테스트에 관여안하는 Log성 Data도 포함)과 똑같으면 이상적입니다. 대용량 테스트는 TestDB의 디스크풀을 나게할수 있음으로, DBA와 모니터링 협조합니다.

• 성능테스트는 주로 프로젝트 마무리 기간에 수행이되며, 성능이슈로 코드수정시 기능검증된 QA를 다시해야되는 불편한 상황이 생길수 있습니다. 풀테스트를 다시진행하여 개발완료시간을 소모하는 일이 발생하지 않게, 변경 영향범위를 최소화하여 예측해야합니다.

성능 테스트 결과물

가상시나리오 Time라인/EndPoint별 성공률	Image Modified
사용자 시나리오가 반영된 Endpoint/시간별 성공그래프	Image Modified
네트워크량 변화 측정	Image Modified
API 지속력 측정	Image Modified

기타정보: 3만명 가상 동접의 Load테스트 목표와 테스트 히스토리

...

성능목표

...

-부하테스트 스크립트를 최초에 작성시에는, 특정한 스텝을 잘못수행하여 API Error를 유발할수 있습니다. (돈이 없는데 결제를 계속 한다던지? / 중복로그인을 계속한던지? 등등 ) 초기에 Error는 테스트 스크립트가 잘못된게 대부분이며 다음과 같은 초기 구축시 어려움이 있습니다.

...