이해하면 2016-10

스토리지 병목이 예상됨니다.
운영체제가 어떻게 되나요?
메모리는 풀 메모리에 레지스트리로 하셔야 하구요
이왕이면 이중화가 좋지요.

이사무엘 2016-10

윈도우 서버 2012 입니다..

luiseok 2016-10

ㅎㅎ이 게시글을 D로 시작하는 모 유머사이트에서 본적 있는것 같은데ㅎㅎ
그때 댓글로도 작성했지만 3만명을 단일 서버로 버틴다는것은 조금 무리가 있습니다.
지금 사양을 조금 낮추시고  서버를 나눠서 구성하는게 좋을것 같습니다.
윗 댓글과 마찬가지로 쓰고나니 스토리지 병목이 예상되네요..
그리고 하드웨어 문제로 데이터손실이 생겼을때를 대비하여 백업대책도 강구하시는게 좋을것 같습니다.

이사무엘 2016-10

으.. 보셨군요...
원랜 계정도 저희 서버에서 처리하려고 했는데
카카오계정으로 다 넘겨버려서.. 충분히 가능할거라고 봤습니다..
근데 다들 IO병목이 생길것으로 예상하시는군요.. ㅠㅠ
사양을 제온 E3정도로 낮춰도 문제 없을까요?
사실 돈이 제일 큰문제라서요..

우야노 2016-10

너구리는 잘 돌아가겠으나..
3만명 기준이  일누적인 동접인지도 고민 하셔야겠네요

이사무엘 2016-10

애플리케이션을 쓰는 사람이 3만명인걸로 잡고 계십니다.
제가 생각해도 동접 3만명은 무리고..
애플리케이션에서는 서버에 데이터버전을  데이터 버전이 클라이언트가 이미 최신이라면, 서버와의 통신은 없고,
만약 버전이 다르면 그때만 데이터를 전송 받는 역할을 하게 됩니다...

Sakkaro홍승현 2016-10

어짜피 보내는 데이터가 "최신 데이터" 하나이기 때문에 램드라이브 혹은 루프디바이스에 최신 데이터만 넣어놓으면 스토리지 병목 현상도 최소화 할 수 있을 거 같습니다.

봄들판에서다 2016-10

클라이언트 업그래이드용 푸쉬 서버군요.
클라이언트 업래이드시(평일 오잔 8시부터 10시 사이) 동접 3만명 나올 가능성도 있기에 서버를 더 두어야 할거 같내요.

사용자 1명당 푸쉬.완료하는 시간을 계산해 보세요. 3만명이 끝나려면 어마어마한 시간이 걸릴겁니다.

이규섭 2016-10

서버에는 버전체크 기능만 구현하고, 버전정보 혹은 해쉬값 정도만 DB에 올려놓고
실제 데이터 다운로드는 CDN 서비스를 이용한다면 동접자가 몰려도 IO 문제가 전혀 없을 것이고
시스템 또한 훨씬 더 가벼운 시스템을 구축할 수 있을 것입니다.

박문형 2016-10

호스팅회사에서 가상서버 구해서 BMT 해보시는 것을 추천합니다..

실제와 이론은 완전히 다르기에...