2008/6
ODBC를 써서 상용화된 게임서버를 운용중이구요
DB에 쿼리를 마치 메모리에 기록하듯이 수시로 날리는게 아니라면
( 아이템 생성과 같이 중요한 정보는 생성순간에 바로 쿼리를 날리지만
아이템의 위치정보같은것은 게임서버에 캐싱해뒀다가 주기적으로 업데이트 하는식으로
쿼리 호출 빈도수를 줄입니다,
아이템이 생성되지 않는것은 유저입장에서 큰 문제가 되지만 '클레임 사유'
위치정보는 아이템의 존재여부에 관계없으니 일부 누락되더라도 큰 문제가 안되죠 )
ODBC때문에 부하가 많이 먹지는 않습니다
쿼리호출자체의 부하보다는 비효율적인 테이블 구조 및 잘못된 인덱스 정의라든가
비효율적으로 짜여진 쿼리 등등의 부하가 훨씬 많이 듭니다.
쿼리 최적화라든가 튜닝과정을 한번 거치고 나면 ODBC는 문제가 안될겁니다.
쿼리호출이 지장될만한 부분이라면.. 쿼리 호출 함수가 블록킹 함수라는것 정도일까요
( 게임서버가 직접 호출한다고 해서 오버헤드가 심해지거나 뭐 그런건 없었습니다.
일단 물리적으로 DB머신과 게임서버머신은 분리되어 있는 상황에서 쿼리를 날리는 동작자체는
내부적으로 일반적인 TCP통신의 비용소모와 비슷한것 같네요, 그 비용도 내부네트워크이기
때문에 거의 없다고 보면 될듯 )
저희는 게임서버에서 직접 DB커넥션 맺고 바로 쿼리를 날립니다만
게임로직 스레드에서 DB쿼리를 호출하지는 않습니다.
DB쿼리를 위한 ThreadManager를 따로두고 DB쿼리를 할때는
DBThreadManager에 event를 queueing해서 workerthread가 쿼리호출을 하도록 하고있습니다
( 대략 10개 내외의 쿼리호출용 WorkerThread를 가지고 있습니다, 갯수는 머신스펙이나
상황에 따라 유연하게 세팅하구요 )
따라서 쿼리 반환이 엄청 늦어지더라도 게임로직에는 영향이 없습니다
그래도 부하가 크다면 OLE DB를 쓰거나 머신을 업그레이드 하거나 DB캐싱서버를 두거나 하면 되겠죠
그래도 일단 서버는 단순한게 제일 좋은것 같습니다 ㅇㅅ ㅇ~
'온라인게임' 카테고리의 다른 글
| 진저브레드 (0) | 2010.10.25 |
|---|---|
| 달라진 아이폰 앱 개발자 정책 (0) | 2010.10.25 |
| 리스트 삭제 체크시 (0) | 2010.10.22 |
| 신형 맥북 에서 ( ? 울트라 슬림 ) (0) | 2010.10.21 |
| 정렬 (0) | 2010.10.21 |