그래서 크래쉬가 나는거 해결했고
이것을 조금더 빡세게 테스트를 해볼려면
Listener에서
만약 더미클라에서 동시에 500명씩 접속을 하려고 하면은
그중에서 일부는 연결이 안될 것이다.
why? => 지금 문지기가
backlog를 10명만 인정을 하고있기 때문.
그래서 원래는 문지기를 10명 for문으로 만들어 줬는데
register라는 값으로 만들어 주도록 하자.
그러면 동시다발적으로 연결 요청이 밀린다고 하더라도
멀티쓰레드 환경에서 이것을 잘 분배를 해서
처리를 해줄 것이다.
그래서 이제
DummyClient > Program
이 숫자를 늘려가보면서 테스트를 해보면됨.
그래서 우리가 JobQueue에 대해서 잠깐 알아보고 구현을 했는데
Job Queue #1 에서 두번째 방법으로
수동으로 만든다고 했는데
이말이 무슨뜻인지 알아보도록 하자.
우리가 이렇게 하나하나의 함수를 파는 행동을
이런식으로 클래스를 하나하나 만들어서 직접만들어야 한다.
"차이"가 생긴것이다.
개인적으로 이런식으로 하나하나씩 맞춰주는 수동적인 방식이 안좋은거같다.
그런데 프젝에서는 7 : 3 비율로 이런 방식을 많이 쓴다.
아직 "람다캡쳐"라는 개념이 나온지 어마어마하게 오래되지가 않아서..
어쨋든 둘다 중요한것이
요청 == 일감이 오면 바로 처리를 하지않고
Queue에다가 일감을 밀어 넣은다음에
순차적으로 일을 한번에 실행했다는 것이 중요하다.
그래서 이제 고민을 해야할게
이 _jobQueue혹은 TaskQueue를 누가? 들고 있어야할지가
고민스러운 부분이다.
예를들어 바람의 나라 같은 경우
player가 움직이는데 어느정도 움직이면 다음 존이 나오고 할때는
그 존에다가 잡큐를 관리하도록 하면 쉽게 해결이된다.
근데 와우, 리니지 같은 심리스 같은 경우에는
심리스 뜻
https://post.naver.com/viewer/postView.nhn?volumeNo=15398932&memberNo=30458888
TaskQueue는 삭제할꺼라
코드 남김
그 다음 해볼 것은
DummyClient > Program
숫자를 늘리면 어떻게 될까??
동접이 만명이라고 해도
같은 구역이 막 100명씩 몰릴일은 거의 없을 것이다.
그런데 일단 최악의 상황이라 가정을 하고 숫자를 늘려보는 것이다.
500명까지는 잘 받는다.
지금은 패킷을 어마어마한 속도로 막 받고있는데
나중에 테스트를 할때는 여러가지 시나리오로 테스트를 해보아야한다.
그리고 하나 더 고민을 해보자면
어떤 개선사항을 볼수 있냐하면은
GameRoom의 이부분이 부화를 굉장히 많이 주고 있다.
지금 500명애들이 500명한테 뿌리는 작업을 하고있으니까
0.25초마다 25000번의 패킷전송을 하고있는 것이다.
그래서 이부분에서 부화가 걸리는게 당연한 부분이다.
그래서
이런부분을 처리를 할 때는
어떤식으로든 n^2보낼게 아니라
어떤식으로든 패킷을 뭉쳐서 보내야 된다.
이렇게 요청이 왔다고 바로 Send를 하는게 아니라
Send도 보면은
이런식으로 큐에다가 쌓아두고 있었다.
그래서 차곡차곡 쌓아가지고 0.1초마다 Send를 한다거나 하는 방식으로 구현을 하면은
N ^ 2아니라 N까지 줄일 수 있다는 얘기이다.
그래서 BroadCast같은 부분은
패킷 모아보내기가 필요하다.
그러면 이제 다시 고민되는게
패킷모아 보내는것을 Server Engine딴에서 할지
아니면 컨텐츠 딴에서 할지는
다음문제기는 한데
다음시간에 해보도록 하자.
