Serverperformance - Ein "In-Depth"-Look auf die Hintergründe - Einfach und verständlich

"GrieferGames.net" ist ein Servernetzwerk, welches aus mehreren einzelnen Servern besteht. So ein Server arbeitet wie ein PC mit einem oder mehreren Prozessoren, Festplatten, RAM, einem eigenen Betriebssystem und einer eigenen Software...

In diesem Fall haben wir ein Serversystem, welches über ~30 "eigenständige" Server verfügt, die miteinander verbunden sind und Daten austauschen können.

Der Hauptserver, der die restlichen Server verwaltet und damit die "Zentrale" darstellt, arbeitet mit einer Software namens "Waterfall", einer sogenannten Fork (einem weiterentwickelten Ableger einer anderen Software) von "BungeeCord". Diese Software sorgt für das Austauschen von Informationen zwischen den einzelnen Servern, das Weiterleiten von Spielern und dient als Basis für das Installieren von PlugIn's.

Ich bezeichne diesen Server gerne als den "Server 0". Mehr dazu gleich...

Verbindet man sich mit GrieferGames.net, leitet einen der "Server 0" auf einen anderen Server um. Dadurch landet man auf einem von 2 Hubs, der sogenannten "Lobby". Dieser Server ist der "Server 1".

Über diesen erreicht man die einzelnen Spielmodi, sowie die Portalräume zu den CityBuilds.

Die einzelnen Spielmodi (Gestrandet, SkyBlock, HardCore, CB Zer0) & die CityBuilds, sowie die Farmwelten Wasser & Lava (also alles, was man aus dem Portalraum heraus betreten kann) sind jeweils eigene Server.

Durch das Betreten des Portals und das anschließende "teleportieren" wird der Spieler wieder (technisch gesehen) auf einen anderen Server verbunden. Je nach ausgewählten Portal zum Beispiel auf "Server 5" für CB2 oder "Server 16" für CityBuild Extreme... Diese CB-Server laufen mit einer Variation der Software "Paper", welche besonders große Mengen an Daten laden & verarbeiten kann. "Paper" ist eine Fork von "Spigot", welches wiederum eine Fork von "Bukkit" ist, der grundlegenden Basis-"Serversoftware" für Minecraft-Server.

Zusätzlich sind auf den Servern sogenannte PlugIns aktiviert, welche spezielle Funktionen hinzufügen (z.Bsp.: Plot², welches die Plotverwaltung auf dem Server hinzufügt oder SkyBlocks, welches das System der Inseln implementiert) oder diverse Einstellungsmöglichkeiten bieten (Deaktivieren von Animationen, Festlegen von Einstellungen unabhängig vom Spielclient, etc.). Der Server hat eine Vielzahl dieser PlugIns für verschiedene Zwecke (WorldEdit, Plotverwaltung, AntiCheat, Duplizierungsvorsorge, Überwachung von Daten, DDos-Abwehr, etc.)

Diese PlugIns müssen zur Server-Software & zur verwendeten Minecraft-Version kompatibel sein. Will man jetzt also Änderungen an Paper (für die einzelnen CB's), an BungeeCord (für den Datenaustausch zwischen den Servern) oder an der Minecraft-Version (neue InGame-Items, Funktionen, etc.) vornehmen, muss man alle anderen Programme ebenfalls an diese Änderungen anpassen.

Baut man nun eine eigene Server-Software, müssen die anderen ebenfalls komplett selbst entwickelt werden...

Daher kommt es, dass die meisten "großen" Servernetzwerke immer noch auf Minecreaft 1.8.9 laufen, obwohl inzwischen bis auf 1.14.x entwickelt wird... Der Großteil aller PlugIns und Serversoftware ist auf 1.8.x ausgelegt.

Zum Verständnis, wie Minecraft (als Spiel) Dinge berechnet:

Jeder Block in der Spielwelt (egal ob Dreck, Holz oder auch nur Luft) ist eine eigene "Entität".

Jedes Monster, jeder Spieler und jeder Gegenstand (der nicht als Block gesetzt ist, sondern einfach herumschwebt... beispielsweise weggeworfene Items...) ist eine "Entität".

Minecraft erstellt die Spielwelt in Chunks.

Chunks sind 16x16x256 Blöcke große Abschnitte und enthalten Biom-Informationen, Blockobjektdaten (z.B. Truheninhalte, Redstone-Status, Schalterpositionen, etc.) und alle Entitäten (Blöcke, Kreaturen, Spieler, etc.). Chunks welche nur aus Luft bestehen, werden vom Spiel nicht geladen und bei der Verarbeitung ignoriert.

Im Einzelspieler muss das Spiel stets nur die Chunks um den Spieler selbst laden. Der Aufwand hierfür ist also recht gering.

Auf den GrieferGames-Servern werden alle Chunks geladen, die in "Sichtreichweite" eines Spielers sind. Diese ist auf dem Server auf 8 Chunks in jede Richtung beschränkt (ca. 3-4 Plots). Alles was sich also in dieser Umgebung (um einen Spieler herum) befindet, muss vom Server geladen werden.

Der Server muss nun diese Daten dauerhaft überprüfen und auf Änderungen reagieren, bis sich kein Spieler mehr in diesem Bereich befindet.

Baust du also einen Block Erde auf deinem Plot ab, wird diese Entity (minecraft:dirt) durch eine andere (minecraft:air) ersetzt. Diese Änderung registriert der Server, verarbeitet sie, speichert sie und schickt sie an alle anderen Spieler weiter, damit auch bei ihnen dieser Block Erde durch Luft ersetzt wird.

Ein weiteres Beispiel ist das Einfahren oder Ausschieben eines Kolbens mithilfe eines Hebels und 3 Stücken Redstone dazwischen.

Legt man den Hebel um aktiviert sich das Redstone und schiebt den Kolben heraus. Legt man den Hebel wieder zurück deaktiviert sich das Redstone und der Kolben fährt ein.

Für den Server passiert folgendes: Die Blockobjektdaten des Hebels werden geändert, die Blockobjektdaten der 3 Redstone-Leitungen werden geändert & die Blockobjektdaten des Kolben werden geändert. Durch den einen "Klick" werden also 6 Blockobjektdaten mit einmal neu gesetzt. Das sind Änderungen an 6 Entitäten. (minecraft:lever, minecraft:air, minecraft:air, minecraft:air, minecraft:piston, minecraft:air)

Der Server muss also alle Änderungen an der Minecraft-Welt verarbeiten, speichern und an alle anderen Spieler auf dem Server schicken...

Zudem sind auf den üblichen GrieferGames-CityBuilds nicht eine oder zwei, sondern 3 Minecraft-Welten existent: Die "Plotwelt", die "Farmwelt" und der "Nether". Der Server darf also gleich 3 komplette Minecraft-Welten auf einmal beobachten.

Es ist daher unerheblich, ob die Minecraft-Welt aus 1 Million Plots oder nur 20.000 Plots besteht oder ob auf CB5 jedes 10. GS oder jedes 2. GS bebaut ist, solange die Spieler, welche derzeit online sind sich nicht in der Nähe zu vieler dieser Plots aufhalten...

Das einfache Laden der Umgebung und Beobachten der Chunks, wäre selbst bei 500 Spielern noch ziemlich einfach, solange sich die Entitäten nicht verändern und der zu beobachtende Bereich klein genug ist.

Ein gutes Beispiel dafür war das Dropevent auf CB8 am 27.01.2019 bei welchem über 500 Spieler auf dem CB waren, ca. 400 davon allerdings auf dem Eventgelände, einem kleinen Bereich, in dem sich nicht wirklich etwas geändert hat. Für über 400 Spieler mussten also nur die gleichen, sich nicht ändernden, 64 Chunks (8x8) geladen und überwacht werden... Dadurch war die Serverlast, trotz der Masse an Spielern, bis zu einem gewissen Punkt (Lags und Zwangs-Kick bei etwas über 700 Spielern direkt zu Eventbeginn, davon mehr als 500 auf dem Eventgelände), nicht über dem üblichen Limit von sonst ~350 Spielern. Der Server hatte für den Großteil dieser Leute also kaum Last zu bewältigen.

Zum Ersten: Die Bukkit-Software, die auf den CB's läuft, war ursprünglich für Server mit bis zu 50 Spieler/Server entwickelt und wurde später mit einigen Performanceverbesserungen auf 100 Spieler/Server optimiert... Niemand hätte erwartet 200-300 Spieler auf einen Server zu packen...

Wenn also die 64 Chunks um jeden Spieler geladen, überwacht und an alle anderen Spieler versendet werden müssen, wird mit jedem Spieler/Server weniger auch die Last weniger. Daher wurden die Slots/CB auch mehrfach verringert...

Zum Zweiten: Schnelles Ändern von Entitäten & Blockobjektdaten. Einer der Hauptgründe für die bisherigen Maßnahmen ist dieser Punkt.

Große Trichter-Anlagen zum automatisierten Sortieren & Lagern von Items belasten durch die permanente Änderung der Blockojektdaten den Server. Je größer dabei die Anlage, desto mehr Last für den Server. Jede Änderung des Trichterstands ist eine Änderung der Blockobjektdaten dieses Trichters. Die "Tickrate" von Trichtern wurde daher soweit angepasst, dass diese nun mehr Items (12) als vorher auf einmal durchlassen.

Redstone wird so stark im Auge behalten, wegen sogenannter "Redstone-Clocks", im Grunde Schaltkreise aus Redstone, welche das Signal in schneller Abfolge aktivieren & deaktivieren können. Jede Aktivierung & Deaktivierung des Signals hat Änderungen der Blockobjektdaten aller betroffenen Entities zufolge.

Das Stacken von Monstern wurde ebenfalls erfolgreich eingesetzt, da durch das Stacken statt 4, 5 oder 20 Entitäten nur noch 1 geladen werden muss.

Wie oben erwähnt, beobachtet der Server 8 Chunks in jede Richtung um jeden Spieler, verarbeitet die entprechenden Daten und aktualisiert diese an jeden anderen Spieler auf dem Server.

Findet dies korrekt statt und der MainThread arbeitet die Daten vollständig ab (und das mit einer Menge von 20 mal pro Sekunde), äußert sich dies bei einer 100% Serverperformance. Man spricht dann von 20 TPS (20 ticks per second).

Kann der MainThread die Daten nicht mehr 20 mal in einer Sekunde abfragen, reduziert er die Menge an Abfragen/Aktualisierungen. Die "TPS" sinken. Dies entspricht einer sinkenden Performance und äußert sich je nach Beeinträchtigung durch Lags (kurze Aussetzer), "Rubberbanding" (Zurückspringen des Charakters), "Block-Bugging" (gesetzte Blöcke verschwinden, abgebaute Blöcke tauchen wieder auf) oder "Ghost-Blocks" (abgebaute Blöcke sind nicht sichtbar, aber immer noch vorhanden).

Aufgrund des oben erwähnten, ist das Eröffnen neuer CB zwar hilfreich, was die Menge an Spielern/Server betrifft (neue Spieler können sich auf "leerere" Cb-Server verteilen, statt die bisherigen "bereits überfüllten" Server zu nutzen). Andererseits waren zum Teil CB's selbst tagsüber auf rund 100/250 Spielern, während andere zu diesem Zeitpunkt bei 380/300 standen. Die CB's Nature, Extreme & Evil sind zum Teil sehr wenig besucht. Nachts kann es schon mal sein, dass man alleine dort sitzt...

Eine Entlastung einzelner CB durch das bloße Hinzufügen neuer CB's findet also nicht statt... Man muss die Spieler auch dazu bringen, sich auf die anderen Server zu begeben. Da das nur in einem begrenzten Rahmen klappt, müssen auch die Maßnahmen diskutiert und durchgeführt werden, die die aktuellen CB's von Serverlast befreien...

Da dies zudem schneller geht und man so Möglichkeiten findet auch andere/neue CB's direkt ab Start zu entlasten, werden diese derzeit getestet... bevor eine Entscheidung zu weiteren neuen CB's kommt, welche ggf. noch nicht benötigt werden, da genug Platz auf anderen da wäre.

Ein wesentliches Problem ist, dass der MainThread, die "Verarbeitung der Daten" auf einen einzigen Prozessorkern auslegt.

Ist also auf einem Server zu viel los und auf einem anderen weniger, kann man die Daten nicht einfach von einem Server zum anderen senden, damit dieser die Verarbeitung vornimmt...

Bei anderen Anwendungen von Servern, selbst bei anderen Onlinespielen ist diese Serverredundanz üblich. "Bukkit" unterstützt dieses Feature allerdings nicht. Selbst ein Multikernprozessor (DualCore, QuadCore oder EightCore) auf einem Server bringt also keinen Vorteil, da der MainThread immer nur einen Kern ansteuern würde und die Leistung verloren ginge...

Viele Prozesse können zudem bei Minecraft nicht asynchron abgearbeitet werden, da sie mit anderen in der Spielwelt zusammenhängen.

Beispiel: Es wäre wirklich unangenehm Tiere unabhängig vom Spieler abzuarbeiten. Wenn man ein Tier reitet, landet man plötzlich selbst woanders, als das Tier.

Somit fällt auch eine Virtualisierung von mehreren Prozessoren auf einen aus. Der "virtualisierte" Einzelkern würde die Aufgaben an mehrere physische Kerne verteilen, was die Abarbeitung nicht nur "verzögert", sondern möglicherweise auch asychronisiert und dadurch insgesamt zu mehr Problemen führt, als es löst.

Übliche Einfachkerne wurden bis zu einer Taktfrequenz von 4 GHz produziert, höhere Taktfrequenzen sind zwar in der Theorie möglich, jedoch aufgrund technischer Schwierigkeiten kaum realisierbar. Ein großes Problem stellt dabei die entstehende Wärmeentwicklung dar, welche bei Feldtests mit einem 5,2 GHz-Prozessor trotz massiver Kühlungssysteme nach wenigen Minuten wegen Überhitzung einen Defekt erleidete.

Ab Mitte 2006 wurden daher die MultiCore-Prozessoren erstellt, welche durch den Einsatz mehrerer Prozessorkerne kostengünstig eine höhere Taktfrequenz und Datenverarbeitung zuließen.

Die Weiterentwicklung von Einzelkernprozessoren ist seitdem sehr geringfügig und bezieht sich in der Regel nur Optimierung von Rechenoperationen und dem Handling von Virtualisierungen.