성능 시험
성능시험 (로드 테스트로도 알려져 있음) 은 서버측 구현사항과 하드웨어가 실제로 예상하는대로 로드를 처리하는지 검증하는데 권장되는 방법 입니다.
어떤것이 예상되는 것 인가요?
종종 간단한 질문을 받곤 합니다:얼마나 많은 동시접속 사용자(CCU)를 Photon 서버가 처리하나요?
불행하기도 이에 대한 답변은 간단하지가 않습니다. 몇 가지의 팩터가 있는데 예를 들면 다음과 같습니다:
- 게임 룸의 클라이언트 수
- 메시지 비율 (혼합: 룸과 초당 메시지 수)
- 메시지 크기
- 프로토콜 타입 (신뢰/비신뢰)
- 클라이언트 플랫폼
- 서버 하드웨어 스펙
- 기타 등등.
전형적인 유즈 케이스에서는 ~ 200 메시지 / 룸 / 초 입니다.
아래는 표준 환경 설정 입니다.
- 1 quad core CPU (예, Intel Xeon 3440, E3-1230 등.)
- 4 GB RAM
- 1 GBps NIC / uplink port 속도
Photon 은 서버당 1000 - 2000 CCU 를 표준 환경 설정으로 처리할 수 있습니다.
보틀넥은 CPU가 아닌 NIC/대역폭에 달려 있습니다.
대역폭 & 트래픽 풀은 CPU 보다 훨씬 비용이 많이 들기 때문에 더 효율적으로 사용하기 위해서 종종 작은 서버들을 운영 하곤 합니다.
일반적으로, bare metal 서버들은 VM보다 더 좋은 결과를 주고 있습니다.
하지만 위에서 보인 숫자들은 개략적인 예상치입니다.
나만의 유즈 케이스에서 튜닝하고 로드 테스트를 통하여 적합한 숫자를 얻을 필요가 있습니다.
테스트 시나리오 식별 하기
로드 테스트를 하기 전에, 유즈 케이스를 설명하고 선행 계산을 수행 하세요.
내 서버에 대한 하드웨어 스펙은 무언인가?
게임에서 얼마나 많은 CCU 가 예상되나?
어떤 타입의 게임이며 어떻게 매치메이킹이 수행되고 기능별로 서버가 분리되어 있나?
Photon Server SDK의 코드를 수정하지 않고 사용하는지 또는 커스텀 코드가 있나? 그렇다면 주요 변경 부분은 무엇인가?
룸당 몇 명의 클라이언트가 있나?
얼마나 많은 메시지가 전송되나?
- 예: 4 클라이언트 / 룸, 매 100ms 당 RaiseEvent() 호출
- 수신: 4 * 10 메시지 / 초 = 40 메시지 / 초
- 발신: 4 * 40 메시지 / 초 = 160 메시지 / 초
- 총: 200 메시지 / 룸 / 초
- 예: 4 클라이언트 / 룸, 매 100ms 당 RaiseEvent() 호출
평균 메시지 크기는?
- 예:
- 200 메시지 / 룸 / 초 * 200 byte = ~ 40 kByte / 초 / room
- 예상: 1000 CCU / 250 룸 => 총 ~ 10 Mbyte / 초
- 예:
위의 예에서 보인 숫자를 가지고 업링크 포트 속도는 100 MBit/s 에 근접하게 상한 값이 가까워 졌습니다.
몇 클라이언트 라이브러리들은 내장 "네트워크 트래픽 통계"를 가지고 있어서 이러한 질문에 대한 답변을 도와 줄 수 있을 것 입니다.
테스트 클라이언트 구축
Photon 은 수많은 연결과 트래픽에 대하여 처리할 수 있도록 최적화 되어 있습니다.
아무튼 클라이언트 SDK 와 라이브러리들은 로드 테스트에 사용되도록 의도 되지는 않았습니다.
클라이언트측은 Photon 과 동일한 방식으로 최적화 될 수 는 없습니다.
대부분의 경우에 있어서 "게임 클라이언트" 의 구현은 로드 테스트 하기를 원하는 시점에 이미 완료되었을 것 입니다.
따라서 실세계 게임 클라이언트를 로드 테스트에서 쉽게 재사용 하는 것을 생각 할 수 있습니다.
하지만 Photon 의 클라이언트 SDK 로 "로드 테스트 클라이언트"를 구축하려고 한다면 클라이언트는 보틀넥이 되고 잘못된 결과로 혼란스러울 것입니다.
좋은 테스트 클라이언트를 구축 하는 것은 로드 테스트에서 정말 힘든 일 입니다.
우리는 다음과 같은 접근 방식을 권장합니다:
- 게임 클라이언트가 전송하는 전형적인 오퍼레이션의 순서/이벤트를 기록 합니다.
- 게임 클라이언트의 행위를 최소화 하는 간단한 Photon 서버(!) 어플리케이션을 구축 합니다.
- "S2S 로드 테스트 어플리케이션" 과 "서버측" Photon 간의 연결을 성립해주는 Photon 의 서버-서버 기능을 이용 합니다.
Photon 환경 설정
Photon / PhotonServer.config:
- 기본 환경설정을 사용하고 변경하지 마세요.
- 기본 환경설정은 다양한 종류의 유즈 케이스에 최적화 되어 있습니다.
모든 변경사항은 예측 하지 못한 영향을 주게 되며 테스트 결과에 대한 이해와 분석이 더 힘들어 지게 됩니다.
Logging / log4net.config:
- 모든 log4net.config 파일들에서 로그 레벨이 "INFO"로 되어있는지 확인 해 주시기 바랍니다.
- "DEBUG" 레벨의 과도한 로깅은 엄청난 성능 영향이 있으므로 피해야할 필요가 있습니다!
- 로깅에 대해서는 다음 링크를 통해 더 알아 보시기 바랍니다:https://logging.apache.org/log4net/release/config-examples.html
테스트 수행하기
- Photon S2S 로드 테스트를 물리적으로 분리된 머신에 호스트 하세요.
- 경험상으로 각 "서버측" Photon 최소 2개의 "S2S 로드 테스트 머신"이 로드 분산을 위해 필요 합니다.
테스트를 수행 하기 전에 서버측과 클라이언트 머신 모두 성능 카운터 설치와 성능 카운터 로그가 생성되어 있는지 확인 해 주세요:
- 실행되고 있다면 Photon 을 중지 합니다.
- Photon Control -> Performance Counters -> Install Counters, Create Logging Set
- 명령어 라인에서 "perfmon"을 시작 합니다. "data collector sets" -> "User Defined"에서 : 우측 윈도우 pane -> Properties -> set the sample interval to 1 second 에서 photon_perf_log를 선택 합니다.
(1분이 기본값이고 여기에는 충분한 데이터를 주지 않습니다) - Photon을 시작 합니다.
- Photon Control -> Performance Counters -> Start Logging
- 로드 테스트를 실행 합니다.
- Photon Control -> Performance Counters -> Stop Logging
- C:\perflogs\admin 에서 성능로그를 얻습니다.
- \deploy\bin_win64\log 와 \deploy\log 에서 로그 파일을 얻습니다.
만약 Photon Control 이 카운터 로그 생성에 실패 했으면 \deploy\bin_tools\perfmon 에서 다음 명령어를 실행합니다:
logman.exe create counter photon_perf_log -si 00:01 -v mmddhhmm -cf logman.config.txt
성능 분석과 보틀넥 식별
부하를 분석하기 위해서 perfmon 에서 성능 카운터를 로드 합니다.
Photon Server SDK 의 "doc" 폴더에는 모든 카운터들이 나열되어 있고 간단한 설명이 들어 있는 "photon-perfcounter.pdf" 파일이 있습니다.
"overall" 부하 판단:
최초 판단을 위해서 "obvious" 카운터를 보세요 : CPU 부하, 피어 개수/활성 연결, 프로세스당 메모리 사용량, 연결해제, 네트워크 트래픽(수신/송신/총 바이트수) 등
이러한 카운터들은 서버가 예상한 부하량을 처리하고 있는지 보여 주며 만약 보틀넥이 있었다면 추가적인 조사가 필요 합니다.
송신 트래픽 (클라이언트가 Busy 한가요?):
위에서 언급 한 대로, 클라이언트 측은 종종 보틀넥이 발생 합니다. 초당 명령 재전송(만약 클라이언트가 ACK 를 전송하지 않아 Photon 이 명령어를 재전송)양, 큐에 쌓인 신뢰 명령어의 양(전송되었으나 ACK가 없는 명령어의 양)등과 같이 어떻게 "outgoing" 트래픽이 처리되어야 하는지 검토해 보세요.
만약 이러한 값이 매우 높다면 클라이언트 측의 문제가 있는 경우가 많습니다.
모든 경우에 대해서 이러한 카운터를 검토 해야하고 클라이언트 측의 보틀넥을 식별했다면 해결 후 다시 테스트를 수행 해야 합니다.
수신 트래픽 (서버가 Busy 한가요?):
"active" I/O 수, Business 와 현재 "처리중"인 ENet 스레드, ENet 큐에 있는 메시지들 등을 비교하여 서버가 Busy 한지 체크 해주세요.
이러한 카운터들은 CPU/메모리 사용률에 종종 연관되어 있으므로 이것들로 부터 추가적으로 인지할 수 있는 것이 많지는 않습니다.
지원이 필요 하신가요?
지원 또는 질문이 있으시면 저희에게 메일 [email protected]을 주세요.
최대한 많은 정보를 포함해서 주시고 특별하게 다음을 포함해 주시기 바랍니다:
- "테스트 시나리오 식별" 섹션에 대한 모든 답변
- "테스트 실행" 섹션의 모든 로그 파일과 성능 카운터 로그들