count of send threads in MMOG

MMOG에서는 하나의 플레이어가 한 행동을 그 플레이어를 관심 영역에 둔 플레이들에게
보여줘야한다.

즉, 1:N으로 비례해서 늘어난다.
recv되는 양에 비해서 N배로 send해야 된다는 뜻이다.
단순히 생각하면 recv thread갯수가 r개라면,
send thread갯수는 N*r개로 늘어나야 원활히 돌아가게 될 것이다.

적절한 N은 몇일까?
그것을 변화시킬 factor들은 무엇들일까?

만약, recv량이 send를 digestion(소화)하기 전에 쌓인다면,
send해야 할 량은 계속 쌓이게 될 것이고, 적체되어 latency는 점점 늘어나게 될 것이다.
적체되지 않고 적절한 latency를 유지하는 것. 그것이 디자인 목표가 되어야 한다.

그에 맞게 갯수를 조절해주면 된다.

한 플레이어의 평균 관심(Area of Interest) 플레이어수는 몇일까?
수백 수천명이 함께 전투하는 공성전과 같은 상황에서는 그 평균은 엄청나게 많아진다.
그렇다고 무작정 thread 갯수를 늘리면, context switch가 많아져서 오히려 resource contention시간과 context switch time 자체의 허비만 하게 될 것이다.


또한 다른 쓰레드의 수를 생각하지 않을 수 없다.
멀티쓰레드를 통해서 어플리케이션이 빨라지는 이유는 IO가 blocking되는
시간 동안 CPU를 놀리지 않고 쓰기 때문이다.
IO blocking이 일어날 수 있는 thread는 모두 multi threading의 대상이 될 수 있다.
그렇다고 CPU가 무한하지 않다.
쓰레드만 늘린다고 모두 원활하게 돌아가지 않는다는 뜻이다.

전체적으로 봤을때,
recv thread가 r개, send thread s개, logic thread가 l개, 기타 async call을 하는 thread가 t개 라면,
(r+s*s'+l+t)*CPU 갯수 정도가 아닐까? ( s'는 평균 group broad casting 량)

이 갯수는 실전에서 테스트 해보지 않으면 알 수 없고,
어플리케이션에 따라서 매우 다를 수 있다.
단순한 채팅 서버에서는 특히 다를 것이기 때문이다.

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^