2012-04-11 6 views
14

Piszę sieciową grę wieloosobową po stronie serwera. Gra jest grą RPG i ma absolutną maksymalną pojemność 2000 graczy, ale praktycznie maksymalna liczba graczy wynosi około 300, choć może być wyższa lub niższa. Najdłużej, za każdym razem, gdy musiałem tworzyć sieci, w których uczestniczyło wielu klientów, utknąłem w NIO, ponieważ nie wymagało to użycia setek wątków. Niedawno natknąłem się na prezentację PowerPoint, w której szczegółowo opisano dwa modele, i prawie sprawił, że model wątku na klienta wydaje się lepszy od NIO. Znalazłem też miejsca, w których stwierdza się, że stary IO może również przewyższyć NIO.Stary wątek we/wy na model klienta lub wzór reaktora NIO?

Program PowerPoint można znaleźć tutaj (jest nieco stary): http://www.mailinator.com/tymaPaulMultithreaded.pdf.

Nie napisałem jeszcze żadnej treści, więc nie byłoby dla mnie problemem zacząć od początku, gdybym musiał zmienić cały projekt sieciowy. Nie jestem pod presją czasu. Początkowo projektowałem implementację wzorca reaktorowego z NIO (wybierz zdarzenie, wyślij handler'a do obsługi zdarzenia).

Więcej informacji można znaleźć tutaj: http://en.wikipedia.org/wiki/Reactor_pattern

Moja cała realizacja reaktor jest przeznaczony do korzystania z pojedynczej nici. Odkąd przeczytałem, że stary IO może przewyższyć wyniki, faktycznie postawił mnie w dylemacie. Nie chcę projektować skomplikowanego systemu NIO, który wykorzystuje wiele wątków, aby w pełni wykorzystać moc procesora, ale też żartuję, że pojedyncza aplikacja używa ponad 300 wątków. Który wzór pasuje do mojego celu? Zaletą wątku na klienta jest to, że naprawdę wykorzystuje on całą moc procesora z natury, ale jednocześnie maskuje system. Nie wspominając o tym, że rozmiar pojedynczego wątku zajmuje dużo miejsca (po pomnożeniu przez kilkaset razy). Czy powinienem trzymać się wzorca reaktora?

Wiem, że to pytanie jest trochę niejednoznaczne, ale uważam, że muszę zadać pytanie dotyczące konkretnie mojej sytuacji, ponieważ nie mogłem znaleźć pytania na tej stronie ani na stronie internetowej, na której jest mowa o moim rodzaju. Było coś o grze, ale gra miała obsłużyć dziesiątki tysięcy graczy.

Wielkie dzięki! Jeśli potrzebujesz wyjaśnienia, zapytaj!

Odpowiedz

10

Nie chcę zaprojektować skomplikowany system NIO który wykorzystuje wiele wątków, żeby w pełni wykorzystać całą moc procesora, ale także warować na myśl o konieczności jedna aplikacja używać ponad 300 wątków. Który wzór pasuje do mojego celu?

Nasze maszyny JVM działają z więcej niż 500 wątkami w sposób ciągły (w tej chwili znajdują się w ~ 700) ze szczytami w 1000. Nie widzę powodu, by sądzić, że 800 nici jest w pewnym sensie "godne". Zacząłbym się martwić, gdy osiągniesz 10 000 wątków (jako numer parkietu) - może mniej, jeśli masz mniej niż 32-bit. Na pewno będziesz musiał przydzielić więcej pamięci, jak tylko dostaniesz się do 1000, ale nic pod wątkiem 1k nie powinno stanowić problemu. Oto dobra strona na thread creation numbers.

NIO jest najbardziej wydajny, gdy masz dużą liczbę połączeń z nieczęsty IO. Rozwiązuje wiele problemów związanych z asynchroniczną komunikacją i są rzeczy, które możesz zrobić z NIO, których "stare IO" nie może zrobić z punktu widzenia funkcjonalnego (kanały przerywane i nie blokujące IO na przykład), ale obsługa pojedynczego wątku jest o wiele prostszy model i nie dziwi mnie, że może przewyższać wdrożenia NIO w wielu konfiguracjach. Z NIO wykonujesz wiele operacji w kodzie Java, które są wykonywane dla ciebie w JVM lub nawet jądrze w natywnym kodzie.Multipleksowanie strumieni i obsługa gotowych IO to wszystko, co dostajesz "za darmo" (pod względem złożoności) za pomocą modelu "starego IO".

Utrzymałbym to w prostocie i trzymałem się wzorca wątku na klienta, dopóki nie będziesz miał dobrych powodów, by przyjąć trafność złożoności.

+0

Sorry @Martin. Chodziło mi o to, aby zachować prostotę z wzorem wątku na klienta. – Gray

+0

Więc myślisz, że 300 wątków na górze "500" jest "nieistotnych"? –

+0

Nie mam ochoty na dyskusję, ale co, jeśli ciągle piszę dane do zdalnego klienta i czytam od tego klienta? –

Powiązane problemy