35. Worker Thread Pattern
• 효과적으로 락을 제거하기 위해 썼다고 함
• 정확한 개념은 구글을 참고
• 한 줄 요약: 스레드 풀
• 테라에서는 CPU 코어 개수 = 스레드 개수
• 코어의 개수, 성능은 스레드와 비례
36. Worker Thread Pattern
• 서버의 모든 요청은 IOCP
• IoCompletionPortTask
패킷 처리
• TimerTask
시스템의 현재 시간 검사
• ClusterTask
타겟 유효 영역 검사
• 루프 처리 시간에 따라 0 ~ 16ms의
타임 아웃 값을 가짐
41. Cluster Update Queue
• 클러스터를 업데이트 하기위한 Dispatcher
• 전역 변수로 모든 Worker Thread가 공유
• 어떤 행동이 클러스터의 업데이트를 필요로 하면
Worker Thread는 업데이트 큐 뒤쪽에 작업을 추가
• 모든 Worker Thread는 같은 알고리즘을 사용하여
같은 큐를 처리하므로 스레드별 TLS에 저장된
클러스터 정보는 모두 동일해야 한다
48. 클러스터의 특징
• 물체를 검색할 때 락이 필요하지 않다
TLS에서 바로 포인터를 얻을 수 있음
• 물체가 움직인다면 모든 Worker Thread는 TLS에 있는 클러스터를 업데이트 해야 됨
49. 클러스터의 특징
• 클러스터의 장단점
NDC12 MMO 서버 개발 포스트 모템
https://www.slideshare.net/devcatpublications/mmo-ndc2012
38p ~ 47p, 94p ~ 107p, 125p ~ 127p
NDC13 게임 서버 디자인 가이드
https://www.slideshare.net/devcatpublications/ndc2013-19986939
48p ~ 62p
51. Back-End 구현
• 업데이트를 자주 해야 함
• Critical Section이나 Spin Lock을 사용하면?
• Critical Section
Blocking으로 인한 성능 하락
• Spin Lock
급격한 CPU 사용 증가로 성능 하락
52. Lock-Free Executor
• 락이 없는 작업 Dispatcher
• 모든 물체는 멤버 함수의 실행 순서를 보장하기 위해 LFE를 가지고 있음
• 업데이트를 위한 함수 포인터를 Task에 랩핑하고 LFE에 랩핑한 Task를 등록
사실 이렇게 인자를 넘기는게 아니라 Task에 랩핑해서 넘긴다
57. 결론
• 빈번한 업데이트로 인해 Atomic Operation을 활용하여 Lock-Free로 구현
• LockFreeTaskQueue는 논블락킹 동시 큐를 기반으로 하여 함수 호출 순서 보장
• 이러한 Front-End, Back-End 처리 과정은 CPU 사용량을 1/20로 줄임
• 1 ~ 6000명의 유저에 대한 CPU(Intel Xeon E5630) 사용율은 1 ~ 6%
• 대기 시간을 줄임으로써 프리 타겟팅 전투를 가능하게 함