발생한 문제
1. 기본 레이턴시가 200이 넘어감
2. 클라이언트와 이동 동기화 시 레이턴시가 20초가 넘어감
문제 원인
1. 클라이언트 코드에 임의로 레이턴시를 강제로 늘리는 코드 발경
2. 클라이언트 서버 양쪽에서 단기간에 너무 많은량의 패킷을 전송
3. AWS에서 ec2 서버를 연 위치가 미국 버지니아주 북부
4. 빌드를 했을 경우와 안했을 경우의 차이드를 했을 경우와 안했을 경우의 차이
해결방안
1. 불필요한 코드 제거
2. 이동 동기화 패킷 교환 방법을 0.1초 주기로 클라이언트 위주로 변경
3. ec2 서버 위치를 가까운 곳으로 변경
결론
1. 최적화 완료
2. 물리적인 거리가 생각보다 중요함
3. 빌드를 하면 클라이언트 처리 속도가 5배는 차이남 (유니티6 기준)
원인 분석 story
1차
원인 분석
-
처리 속도 문제인가 싶어서 서버에서 체크
=> 문제없음 -
클라이언트 체크
=> 임의로 레이턴시를 강제로 늘리는 코드를 발견 (waitsecond)
처리
- 예전에 사용했던 코드를 긁어오다 잊어버린 것으로 판단하고 전달 후 삭제
결과
- 조금 빨라지긴 했으나 레이턴시가 계속 늘어나는건 여전함
2차
원인분석
- 클라이언트 코드를 분석해 sendQueue와 receiveQueue의 스택 쌓이는 양을 체크
=> sendQueue와 receiveQueue 둘다 심각하게 많은량이 쏟아져 내림
=> 양쪽에서 인터벌로 약0.02초 간격으로 보내줌(너무 많음)
=> 클라이언트 처리 속도로는 쌓이는 속도를 못따라감
처리
- 서버에서는 인터벌로 주지 않고 클라이언트에서 받은 이동에대한 notification을 해주는 것으로 변경
결과
-
receiveQueue는 상당히 줄었으나 쌓이는 속도를 못따라감
-
sendQueue는 여전히 엄청나게 쌓임
3차
원인 분석
- 0.02초마다 이동동기화를 해주는 것이 너무 빠르다고 판단
=> 일반적으로 이동 동기화가 중요한 FPS나 MOBA같은 게임이 0.05 ~ 0.1초 마다 동기화를 해준다고함
=> 현재 우리가 진행중인 프로젝트는 리썰컴퍼니류라 이동 동기화에 그리 힘쓸 필요가 없음
처리
- 이동 동기화를 0.1초마다 해주는 것으로 변경
결과
- 레이턴시가 250~350 사이로 안정적으로 변경됨
4차
- 레이턴시가 안정적이긴 하나 기본 레이턴시가 너무 큼
원인 분석
- AWS에서 ec2 서버를 연 위치가 미국 버지니아주 북부로 되어있는것을 발견
처리
- 서울로 위치변경
결과
- 레이턴시가 50~100 사이로 생각 이상으로 빨라짐
5차
추가 문제
- 4차 결과로 만족을 하였으나 0.05초로 이동 동기화를 해도 레이턴시가 늘어나는 게 이상하다고 생각
원인분석
- 빌드를 했을 경우와 안했을 경우에 속도 차이가 있을 것이라고 판단하여 빌드를 한 뒤 진행
결과
-
동기화 0.05초
=> 정상작동 오히려 레이턴시가 더 짧아짐 30~60 사이 -
동기화 0.02초
=> 정상작동했으나 50~120 사이 값을 벋어나지는 않지만 4차 결과보다 늘어난 레이턴시에 이 이상은 문제가 있을 거라고 판단
=> 이후 에너미 동기화나 추가 유저 동기화를 생각하면 더 많은량의 패킷이 오고갈 것을 생각해 0.1초로 동기화 하기로 결정
개발 하고 싶은 비버