Java-Massive-Multiplayer-Game-Server-Skalierbarkeit

Habe ich ein massive-multiplayer-online-Spiel für Android namens Infinite Black:
https://market.android.com/details?id=theinfiniteblack.client

In meiner Naivität, ich hatte erwartet, mäßige Wachstumsrate von über 1.000 Spieler im Monat, und benötigen, um zu verwalten, ~20 live-TCP/IP-clients tops.

Das Spiel hat unerwartet Explosives Wachstum mit über 40.000 neue Nutzer in einer Woche, und durchschnittlich ~300 live-verbindungen auf einmal, und wächst exponentiell.

Server-Architektur besteht aus 2 threads pro Verbindung (blocking read/write), ein ServerSocket-thread, um zu laichen neue Kunden, und einen controller thread, der fragt jedes client für neue Aktionen, gilt es die Spielwelt, dann spült die Daten wieder heraus, wenn Sie fertig.

Den server gebaut wird in Java, die ich bin nicht sehr versiert, insbesondere in einem high-stress-situation wie dieser. C# hat wirklich verwöhnt mich, wenn es um die Speicher-und thread-management.

Auf den Punkt zu bringen.. ich habe gerade bestellt zwei sehr leistungsfähige Systeme, um als dedicated game-Server und wollen zu maximieren der Ressourcennutzung. Viele der Informationen, die auf Java-Ressourcen-Konfiguration erwiesen, die irreführend, unrichtig oder veraltet sind.

Derzeit nutze ich -Xss512k als meine launch-argument, und verstehen, dass diese diktiert stack-Größe, die Zuteilung für jeden thread, den ich aber noch nicht vollständig verstehen alle, die es mit sich bringen kann. Welche tools oder Methoden verfügbar sind, um mir zu sagen, wenn ich bin hinausschießen und skalieren es runter? Was andere BefehlszeilenArgumente sollte ich beachten?

Den neuen Server mit 16gb RAM und i7-2600K Sandy Bridge 3.4 GHz-Prozessoren: Welche Optionen verfügbar sind, in die Konfiguration zu nehmen, so viel Vorteil wie möglich? Mein Ziel ist 1.200 online-Kunden auf einmal pro server (bis zu 2.400 threads).

Welche Art von unerwarteten Fallstricke und Probleme, sollte ich besorgt sein?

Ich gelesen habe, Wild widersprüchliche Geschichten auf maximale Fadenzahl: Werden sich die Dinge auseinander fallen, wenn ich versuche zu drücken bis zu 2.400 aktive threads?

Java scheint nicht, wie es entworfen wurde, für diese Art von Aufgabe. Sollte ich erwägen eine Migration der server auf eine andere Sprache?

Mir läuft der server im debug-Modus von Eclipse während der Entwicklung (igitt..)

Dies ist mein Eclipse .ini-Konfiguration:

--launcher.XXMaxPermSize
256M

-Xms256m

-Xmx1024m

  • Tatsächlich, Java wurde für diese Aufgabe. 🙂
  • Ja, wer würde jemals gedacht, bei der Verwendung von Java für die massiven Server? 😉 Aber das problem ist leider die ganze Lösung - 2threads/user einfach nicht korrekt skaliert, keine Sprache würde helfen.
  • kegel.com/c10k.html, Wie groß moderne TCP-Server, um Zehntausende von TCP-verbindungen
InformationsquelleAutor Whalesong Games | 2011-09-11
  1. 8

    Sie haben nicht deutlich gemacht, wo deine Zweifel herkommen.

    Plurk Kometen: der Umgang mit mehr als 100.000 Gleichzeitige Verbindungen mit Netty (2009)

    1999 habe ich implementiert eine Java-web-server, der verarbeitet die 40.000 gelbe Seiten Suchabfragen pro Stunde (der Server hatte 400 MHz-CPUs) und in 2004 habe ich die Entwicklung einer Java-Anwendung, die behandelt 8000 gleichzeitigen verbindungen pro server (auf einem dual-1,2 GHz-Sparc-Servern) gab Es sechs Tor-Servern und einem Haupt-server, die Steuerung und Zentralisierung der Ereignisse.

    Ihrem Profil wird wahrscheinlich anders sein, aber ich kann sagen, dass die Java-Unterstützung wurde hohes Volumen von web-Servern, bevor Sie C# veröffentlicht wurde.

    Persönlich würde ich nicht mehr als 10.000 gleichzeitige verbindungen pro server, aber das ist nur eine Faustregel, die unter Umständen nicht mehr halten. Sie können 32,000 threads in einer JVM. Auf Linux geht es nicht viel über diese. Allerdings hätte ich mir mehrere gateway-JVMs auf einem einzelnen server zu minimieren, Ihre vollständige GC-Zeiten (der beste Weg zur Minimierung der full GC-Zeiten ist zu verwerfen, weniger Müll, aber dies könnte erfordern mehr Aufwand)

    Den neuen Server mit 16gb RAM und i7-2600K Sandy Bridge 3.4 GHz-Prozessoren: Welche Optionen verfügbar sind, in die Konfiguration zu nehmen, so viel Vorteil wie möglich? Mein Ziel ist 1.200 online-Kunden auf einmal pro server (bis zu 2.400 threads).

    Ich kann mir nicht vorstellen, warum das ein problem sein.

    Welche Art von unerwarteten Fallstricke und Probleme, sollte ich besorgt sein?

    Denken, Sie brauchen, um jeden möglichen Befehl Linie parameter, wenn es wahrscheinlich ist, können Sie alle von Ihnen entfernt. Wenn du 4-gateway-JVMs mit 300 Verbindung jede, dieser können alle Speicher und Sie müssen nicht einmal angeben, die -Xmx Einstellung.

    Java scheint nicht, wie es entworfen wurde, für diese Art von Aufgabe. Sollte ich erwägen eine Migration der server auf eine andere Sprache?

    Sind Sie besser Fragen Sie sich, warum Sie dies glauben. Sie haben ein problem, das sollte einfach zu lösen oder eine Frage, die möglicherweise oder möglicherweise nicht unbegründet.

    Dies ist mein Eclipse .ini-Konfiguration:

    Konfigurieren Sie eclipse hat keine Sperre auf, wie ein Programm ausführen aus eclipse eingestellt ist.

    BufferedOutputStream ist gut für die meisten Anwendungen und ist wahrscheinlich gut für bis zu 1000 verbindungen in einer JVM. Allerdings Java 1.4 (2002) Hinzugefügt NIO, die eine mehr Licht Gewicht für die Skalierung von Ihrem system zu 10.000 verbindungen und darüber hinaus.

    BTW: Der server entwickelte ich im Jahr 2003 wurde auf der Grundlage NIO dispatcher, aber es ist ziemlich kompliziert, es sei denn, Sie verwenden eine standard-Bibliothek, wie Netty.

    Da habe ich dann verwenden Sie eine single-thread-per-connection-Modell für die Sperrung NIO erfolgreich. Ich glaube, das ist einfacher zu verwalten als mit einem dispatcher und können, haben eine niedrigere Latenz Merkmale. Ich habe einen monitor-thread, der in regelmäßigen Abständen überprüft die verbindungen nicht blockieren, schreibt und schließt Sie, wenn Sie sind. Ich glaube nicht, dass Sie benötigen zwei threads pro Verbindung, aber ich glaube nicht, dass es einen Unterschied machen wird, in Ihrer situation, weil Sie nicht genug verbindungen pro server, egal.

    Als glowcoder schlägt vor, haben Sie sich überlegt über UDP-für weniger kritische broadcast-Informationen?

    • Mit einem gateway oder portal zwischen externen Kunden und internen Systemen ist ein gemeinsames Muster in einer Vielzahl verteilter Anwendungen, ob Ihre web-server oder messaging system basiert in Java oder einer anderen Sprache. Dies ermöglicht Ihnen das skalieren der Anzahl der Benutzer relativ leicht.
    • Wenn Sie eine 16 GB-und Sie verteilen Ihre Arbeit zwischen etwa 4 JVMs Sie laufen konnte Sie mit Standard-Einstellungen und noch der ganze server effizient. Sie können finden, Sie möchten etwas zwicken hier und da, aber generell tuning-Parameter sind über verwendet, IMHO. Auf der anderen Seite, es sei denn, Sie haben viel Mühe in die Herstellung Ihrer Anwendung verwenden, Speicher in einer skalierbaren Weise in einer einzigen JVM-Sie werden nicht in der Lage zu verwenden, 16 GB Speicher effizient oder ähnliches.
    • Die 64-bit-JVM hat voll laufen des Speichers, allerdings als ein Spiel-designer werden Sie besorgt über Wartezeit esp worst-case-Latenz. Für eine typische Anwendung der worst-case-Latenz für eine Volle GC ist über eine Sekunde pro GB. Ich gehe davon aus, dass ein 16 zweiter stop der Welt, die GC wäre nicht akzeptabel für die Benutzer.
    • Wenn Sie alle Ihre Benutzer in einer JVM (die ist eine schlechte Idee, aus vielen Gründen), und Sie haben über 30.000 threads wirst du gegen eine Wand.
    • Anders ausgedrückt, was ist die maximale akzeptable Verzögerung können Sie haben? Ich vermute, dass zwischen 0,5 und 4 Sekunden. Das ist wahrscheinlich die maximale Größe (in GB) für jede JVM auf Ihrem system.
    • Kein problem. Wenn Sie eine JVM, die einfachste Sache, die Sie tun, ist geben es fast alle Speicher für seinen heap, sagen 12 GB und sehen, wie er ausführt. Es klingt wie Skalierbarkeit nicht in von der start-und Java wird nicht fix, dass es für Sie (ich kenne keine Sprache, die wird) Sie werden sehen, Skalierbarkeit, aber es sollten alle noch funktionieren oder gemacht werden kann, zu arbeiten, ohne ein re-write.
    • Ich wäre daran interessiert zu wissen, wie .NET macht dieses problem nicht leichter. 😉
    • Lassen Sie mich es zu Ihnen einen anderen Weg. Wenn Sun veröffentlicht Java im Jahr 1996, hatte es bereits veröffentlicht Solaris 2.5 (seine 5. minor-update der 64-bit-OS) von Microsoft hatte soeben seine erste 32-bit-OS ein Jahr zuvor und sein Flaggschiff-Produkt, MS Office, war nicht 32-bit-noch. .NETTO kam 6 Jahre später, und war nicht-64-bit, bis vor ungefähr 4 Jahren. Sun und Oracle haben gezielte größer, server-Systeme, für viel länger (in der Erwägung, dass MS dominiert den desktop-Markt)
    • Ihre Erfahrung mit der Produktivität in C# hat mich nicht überrascht. Visual Studio ist eine hervorragende kommerzielle Produkt. Ich weiß nicht wirklich, wie Eclipse, wie Sie zu benötigen scheint, lädt der schlecht passende plugins, um es vollständig zu sehen. Das ist, warum ich benutze IntelliJ, das ist ein anderes kommerzielles Produkt und viel produktiver IMHO. Es hat eine Kostenlose version als auch.
    • Anstatt C# vs Java, ich vorstellen, dass wir Zustimmen würden, die auf Eclipse vs Visual Studio. 😉
    • btw, warum denken Sie, dass NIO schwer? In ein paar tausend code kann man schreiben, eine anständige server. Die Gewährleistung einer fairen Behandlung der einzelnen Sitzung könnte ein wenig schwierig sein, aber. Noch eine queue pro client-session + queue pro sender-thread ist ein unkompliziertes und einfaches design (und kann völlig lock frei, außer Selector.wakeup, die nur selten benötigt)
    • NIO ist nicht schwer, aber es ist nicht so einfach, wie blocking IO. Ich empfehle nicht, die Dinge komplizierter als Sie sein müssen und wenn die einfachste Lösung wird den job zu erledigen (und in vielen Fällen wird es), würde ich vorschlagen, dass ist der Ansatz zu nehmen.

    InformationsquelleAutor Peter Lawrey
  2. 4

    In Java, jeder thread wird die gleiche Menge an Speicher auf dem stack-wie jeder andere thread. Dies bedeutet, dass Ihre Haupt-thread, sagen wir, es hat einen reservierten Größe von 32k (ich denke das ist Standard), wird die gleiche reservierte Größe wie Ihre Kommunikation von threads (die wahrscheinlich nur brauchen, 1k, wenn Sie über Sie denken!) Dies ist der Grund, warum Java kam mit nio - so brauchen Sie nicht ein thread pro Verbindung.

    Geben wir 1g RAM Beispiel. Mit 32k pro thread, davon haben wir die Hälfte unserer Speicher für den stack und die Hälfte für die Haufen, die wir am Ende mit 512 verfügbar für stack. Das gibt uns Raum 16.384 threads. Dies bedeutet auch, dass unser thread-scheduler zu jonglieren und 16.384 threads. Dies erhöht die chance, dass einer der threads erhalten verhungert. Nun, wenn eine person bekommt verhungert, gut saugt, um ihm sein; wenn main bekommt verhungert, beschissen zu werden ... jeder!

    Mit nio, Sie haben... zwei threads. Haupt -, und Kommunikation. (Man könnte auch tun, ohne in den Kommunikations-thread, eigentlich...). Nun, eigentlich haben Sie wahrscheinlich ein bisschen mehr, als dass Sie ein Spiel haben, loop und so. Aber immer noch 10 threads ist viel einfacher zu planen, richtig als 16k threads!

    Nio ist nicht unbedingt intuitiv zu lernen, aber es lohnt sich.

    Eine Sache, die ich denken würde, wenn du nicht gehst, zu verwenden nio ist nur 1 thread pro Verbindung anstelle von zwei. Sie nicht brauchen, eine zweite für das schreiben: Sie können einen thread mit einer Warteschlange und müssen es tun, alle schreiben für alle clients. Das wird zumindest verdoppeln Sie Ihren Durchsatz für die Zeit.

    • flush()ing, eine Steckdose sollte nicht blockieren, Ihre Java-code - vielmehr sollte es zu einem hardware-Ebene für die Verarbeitung muss damit es gepuffert Teil blockiert. Wenn Sie gehen, um manuell zu Spülen, sollten Sie nicht mit einer BufferedOutputStream. Je nachdem, was Sie senden über, würde ich erwägen DataOutputStream oder ObjcetOutputStream entsprechend.
    • Als indie-game-Entwickler kann ich dir sagen, dass der Wechsel auf nio ist nicht so schmerzhaft, wie es klingt. Es wird ein paar Tage dauern, aber Sie werden in der Lage sein, um service wie viele Kunden auf einem server, da es die CPU-und RAM-Speicher für die Bearbeitung Ihrer Spiel (im Gegensatz zu den Einschränkungen durch den thread-Kommunikation). Meine Schätzung, wenn ich war auf der Suche auf ein mmo waren bei 1k mit herkömmlichen Steckdosen und 15k mit nio. Kaufen 15-mal weniger Servern scheint es mir Wert!
    • Anstatt NIO manuell, möchten Sie vielleicht werfen Sie einen Blick auf Netty (www.jboss.org/netty). Es sollte sich um eine Menge von Sanitär für Sie. That being said, Java sollte leicht zu handhaben, die mehrere tausend threads, ohne Frage, auch wenn Sie nicht alle senden auf einmal, so dass Sie möglicherweise ein kleines Kissen mit dieser sehr neuen Servern.
    • hängt davon ab. In der Regel Ihre Kunden haben zwei threads, werde für die Kommunikation: 1 TCP für wichtige Daten, 1 für UDP für die hintergrund-Informationen. Wenn alles komprimiert in einem thread, die Chancen sind Sie haben einen Konstanten Strom von Informationen
    • können Sie erklären, warum würden Sie haben 2 Kanäle, können Sie synchronisieren müssen 'em-das nervt. Wenn ich mich entscheiden für das UDP-Protokoll nur die übertragung der delta-Zustand (inkl) hintergrund, der einzige Unterschied zwischen TCP/UDP-wäre zugunsten der TCP-Anbieter. UDP kann überleben w/ NAK die meisten der Zeit, sehr zur Verringerung der Bandbreite und Last auf.
    • Sie wollen immer noch Spieler Anfragen (z.B. Bewegung, Aktionen, etc), um durch zu gehen auf TCP. Sonst müsste man, um Ihre eigenen SYN - /ACK - /NAK-Protokoll, das ist einfach nur albern.
    • ja über client-Anfragen, ich meinte hauptsächlich server->client -, client - >server sollten deutlich weniger belasteten Kanal.
    • würde es keine client->server-Kommunikation über UDP. Das einzige, was der client muss dem server mitteilen, ist seine Anfragen. So haben Sie einen UDP-Kanal (broadcast-gamestate-delta), eine TCP-Kanal (zu-server-client-Anforderungen von der server-periodische gamestate aktualisieren zu überwinden UDP packet loss und client-Anfrage-Ergebnisse).

    InformationsquelleAutor corsiKa
  3. -2

    Müssen Sie nicht denken, im laden von Knoten, die weder in der Menge der threads.
    1)
    Wenn Ihr Spiele Maßstab für Millionen Benutzer, die Sie benötigen, cluster-Server loadbalanced durch einen registry -

    2) Jeder Knoten muss sein, geringe Latenz, d.h. jedes eingehende Spieler-Nachrichten und Welt-update-Berechnung (1 tick) getan werden muss, milli Sekunden. Sehr machbar. Keine Notwendigkeit, eine monster-Konfiguration pro Knoten.

    3) rufen Sie dies 30-mal pro Sekunde

    => Sie können Tausende Spieler gleichzeitig auf einem einzelnen Knoten und Skalierung von zehn thousansd Millionen mit region Segmentierung Dank einer registry vor, Ihre Infrastruktur, die dafür sorgen, dass Spieler die verbunden sind, um den besten ping Latenz-game-server.

    Mit diesem Muster geladen 10 000 gleichzeitige Spieler auf Echtzeit-Spiel pro Knoten und +300 000 pro Knoten auf rundenbasiertes Spiel.

    Engpass ist oft IO. Verwenden Sie die SSD für Datenbank-storage.

    Java ist kein problem. 2400 thread ist ein problem. Lösen können Sie das problem mit der Schleife verbrachte Zeit und muss überlegen, unter Millisekunde tick loop.

    HTH

    Nuggeta admin - 100% Kostenlos hoch laden multiplayer-java-game-server

    InformationsquelleAutor Free Java Multiplayer Server
Schreibe einen Kommentar