Lasttests von Gameserver-Verwaltungspanels

Dieser Artikel handelt von Lasttests fünf populärer Verwaltungspanels für Gameserver: GameAP 3, GameAP 4, PufferPanel, Pterodactyl und Pelican. Alle Panels werden auf derselben Hardware unter möglichst identischen Bedingungen getestet; wo sich die Bedingungen nicht angleichen ließen, ist das ausdrücklich in den Einschränkungen vermerkt.

Disclaimer. Dieser Artikel erscheint im Blog von GameAP, und sein Autor ist Entwickler; GameAP 3 und GameAP 4 sind zwei der fünf getesteten Panels. Das ist ein Interessenkonflikt, und Sie haben Recht, Voreingenommenheit zu erwarten. Um ihr entgegenzuwirken, ist der gesamte Test auf Nachprüfbarkeit ausgelegt: Die k6-Skripte, Konfigurationen, rohen k6-Berichte und Monitoring-Metriken jedes Durchlaufs sind in einem GitHub-Repository veröffentlicht. Die Methodik lässt sich Schritt für Schritt nachvollziehen, und der Test kann auf eigener Hardware wiederholt werden. Wenn Sie meinen, ein Panel habe eine falsche Konfiguration erhalten oder eine Schlussfolgerung sei überzogen, öffnen Sie ein Issue: Es wird erneut geprüft und eine Korrektur veröffentlicht. Und noch eine Anmerkung für alle, die nur die kurze Antwort suchen: Ja, GameAP 4 hat hier die besten Zahlen geliefert.

Die Kurzfassung:

• Bei typischer Last (10–100 gleichzeitige Nutzer) arbeiten alle fünf Panels ohne einen einzigen Fehler; was sich unterscheidet, ist die Latenz: einstellige Millisekunden bei den Go-Panels, rund 9 ms bei GameAP 3, mehrere Dutzend Millisekunden bei Pterodactyl und Pelican.
• Die Durchsatzgrenze auf diesem Teststand:
  • 1126 Anfragen/s für GameAP 4
  • 696 Anfragen/s für PufferPanel
  • 394 Anfragen/s für GameAP 3
  • 93 Anfragen/s für Pterodactyl
  • und 76 Anfragen/s für Pelican
• Unter Überlast brechen die Panels unterschiedlich ein: Die Go-Panels beginnen, Fehler zurückzugeben; die PHP-Panels geben überhaupt keine Fehler zurück, aber die Antwortzeiten wachsen auf Sekunden und Dutzende von Sekunden.
• Die größte Überraschung: Bei Sättigung verbraucht MySQL bei Pterodactyl und Pelican fast einen ganzen CPU-Kern, während bei GameAP 3 — mit demselben MySQL und denselben Einstellungen — die Datenbank bei doppelt so vielen Anfragen pro Sekunde dreimal weniger ausgelastet ist.

Ziele #

1. Den Bruchpunkt finden: die Grenze, bis zu der ein Panel noch ordnungsgemäß funktioniert.
2. Die Alternativen unter möglichst ähnlichen Bedingungen vergleichen.
3. GameAP 3 und GameAP 4 vergleichen: was genau die Neuschreibung von PHP nach Go gebracht hat.

Neben dem Gesamtvergleich aller fünf Panels sind drei Direktduelle von besonderem Interesse:

1. GameAP 3.x vs. GameAP 4.x: eine komplette Neuschreibung in Go mit aktualisierter Architektur.
2. GameAP 4.x vs. PufferPanel: ein Vergleich zweier in Go geschriebener Panels.
3. Pterodactyl vs. Pelican: das Original-Panel gegen seinen Fork.

Die Panels #

Alle drei PHP-Panels betreiben zusätzlich Redis (Cache und Sessions). Die Versionen sind auf Ebene der Major-Branches erfasst, Stand April 2026, als die Durchläufe stattfanden.

Was getestet wird #

• HTTP/API-Latenz bei verschiedenen Parallelitätsstufen: Lasttests (10–100 VUs);
• Verhalten unter Überlast (Degradation, Fehler, Ressourcenverbrauch): Stresstests (800–1200 VUs);
• die Durchsatzgrenze ohne Pausen zwischen den Anfragen: Durchsatztests.

Nicht Gegenstand dieses Artikels:

• Schreibanfragen;
• UX, Funktionsumfang, Sicherheit, Ökosystem;
• die Arbeit mit echten Gameservern und ihren Dateien;
• Langzeitstabilität: Es wurden keine Soak- oder Spike-Tests durchgeführt.

Teststand #

Server (Bare-Metal, Selectel):

• CPU: Intel Xeon E-2456 (Raptor Lake, 6C/12T, 3,3 GHz Basis / 5,1 GHz Turbo, 18 MB L3);
• RAM: 32 GB DDR5 ECC (2×16 GB, 4400 MT/s);
• Speicher: 2× Samsung 990 PRO 1TB NVMe im mdadm-RAID1;
• Hypervisor: Proxmox VE 9.1.5 auf Debian 13, Kernel 6.17.9-1-pve.

Konfiguration der virtuellen Maschinen #

Host-Tuning #

• CPU-Governor: performance;
• C-States auf C1 begrenzt;
• Turbo Boost aktiviert;
• Swap auf allen virtuellen Maschinen deaktiviert.

Methodik #

Die Panels werden einzeln getestet: Während ein Panel im Test ist, sind alle anderen VMs heruntergefahren, um gegenseitige Beeinflussung zu vermeiden. Während eines Durchlaufs arbeiten nur das Panel (API), der Gameserver-Daemon, der k6-Lastgenerator und der Monitoring-Stack.

Jedes Panel durchlief drei vollständige, unabhängige Durchläufe der gesamten Profilserie (18.–19. April 2026). Alle Zahlen in diesem Artikel sind Mediane der drei Durchläufe, sofern nicht ausdrücklich anders angegeben.

Die Abfolge für jedes Panel: die beiden VMs (Panel und Daemon) starten → Dienste neu starten → ein Aufwärmdurchlauf des smoke-Szenarios (1 VU, 30 s) → die Lastprofile der Reihe nach. Vor jedem Profil werden die Dienste des Panels neu gestartet; nach jedem Profil gibt es eine 60-sekündige Pause. Die Menge der neu gestarteten Dienste unterscheidet sich zwischen den Panels: Bei den PHP-Panels sind es php-fpm, nginx und MySQL (plus Redis bei GameAP 3), bei PufferPanel die Anwendung selbst, bei GameAP 4 nur nginx. Das ist eine Asymmetrie der Methodik; mehr dazu in den Einschränkungen.

Lastprofile #

Szenario #

Jede Iteration führt drei GET-Anfragen aus — diejenigen, die echte Nutzer am häufigsten stellen: die Serverliste, die Details eines zufälligen Servers aus dieser Liste und dessen Status. Zwischen den Anfragen liegt eine Pause von 0,3–0,8 s, am Ende der Iteration eine von 1–3 s. Das max-throughput-Profil führt dieselben drei Anfragen ohne Pausen aus. Anfragen, die Daten verändern (POST, PUT, DELETE usw.), kommen im Test nicht vor.

¹ GameAP 3.x hat keinen separaten Status-Endpunkt — die Details-Anfrage wird wiederholt.

Jedes Panel erhielt 100 identische Mock-Gameserver (ein Platzhalterskript, das die Uhrzeit ausgibt; die Server wurden nie installiert oder gestartet). Die Antworten der Listen-API unterscheiden sich dennoch: GameAP liefert alle Datensätze auf einmal (die Datenbank des Teststands enthielt 102), Pterodactyl und Pelican liefern die erste Seite von 50, PufferPanel die erste Seite von 20. Die durchschnittliche Antwortgröße im load-Profil beträgt 13–16 KB pro Anfrage bei vier Panels und 1,6 KB bei PufferPanel. Ein direkter panelübergreifender Vergleich der list_servers-Latenz ist daher nicht ganz fair — einer der wichtigsten Vorbehalte dieses Tests.

Authentifizierung und Limits #

GameAP 3/4, Pterodactyl und Pelican verwenden einen API-Schlüssel (Bearer). PufferPanel verwendet OAuth2-Client-Credentials: Das Token wird einmal in setup() geholt und von allen VUs wiederverwendet. Die OAuth-Anfrage selbst (~58 ms) landet in den Statistiken jedes Profils, weil setup() bei jedem k6-Aufruf läuft. Im kurzen smoke-Profil (31–34 Anfragen) hebt sie die durchschnittliche Latenz von PufferPanel von ~2 auf ~3,7 ms, während der Median unverändert bleibt. Bei baseline ist sie eine Anfrage von ~2 200 — rund +0,03 ms (~2 %) auf den Mittelwert, Median und Perzentile bleiben unberührt; bei den längeren Profilen ist der Effekt vernachlässigbar.

Bei Pterodactyl und Pelican wurden die API-Rate-Limits auf 10 000 Anfragen pro Minute angehoben — sonst wäre der Test am Limiter hängen geblieben, nicht am Panel.

Tuning der PHP-Panels (identisch bei GameAP 3, Pterodactyl und Pelican) #

; PHP-FPM
pm = dynamic, pm.max_children = 50, pm.start_servers = 10
; OPcache
opcache.memory_consumption = 256, opcache.jit = tracing, opcache.jit_buffer_size = 128M
; MySQL
innodb_buffer_pool_size = 2G, max_connections = 200, innodb_flush_log_at_trx_commit = 2

Werkzeuge #

• k6 v1.7.1; das Standard-Timeout für Anfragen beträgt 60 s;
• Prometheus, node_exporter 1.8.2 (VM-Metriken, 15-s-Schritt), process_exporter 0.8.7 (Prozessmetriken, 30-s-Schritt).

Das Closed-Loop-Lastmodell #

k6 arbeitet mit einem Closed-Loop-Modell: Ein virtueller Nutzer sendet die nächste Anfrage erst, wenn er die Antwort auf die vorherige erhalten hat. Wenn ein Panel langsamer wird, sinkt die tatsächliche Lastintensität automatisch. In einem offenen System — echte Nutzer, sich automatisch aktualisierende Dashboards, Integrationen — würden die Anfragen unabhängig von den Antworten weiter eintreffen, und ein degradiertes Panel käme noch schlechter weg. Denken Sie beim Lesen der Stress-Ergebnisse daran: Die Zahlen der verlangsamten Panels sind eine optimistische Schätzung. Mehr zu diesem Effekt: Coordinated Omission.

Anmerkungen zum Aufbau des Teststands #

Ressourcen der Panel-VM während des smoke-Profils — 1 VU, bei bereits mit 100 Servern gefüllter Datenbank; Spitzenwert über das Profilfenster, Median aus drei Durchläufen:

Der RAM-Wert bezieht sich auf die gesamte virtuelle Maschine (MemTotal − MemAvailable), einschließlich Betriebssystem, Datenbank und Hilfsdiensten.

Anmerkungen, die beim Aufbau des Teststands gesammelt wurden:

• Pterodactyl und Pelican können nicht hinter NAT arbeiten — weder das Panel noch Wings: Der Browser verbindet sich direkt über HTTP/HTTPS mit Wings.
• Pelican erfordert nach Änderungen an den Einstellungen einen Neuaufbau des Konfigurations-Caches, sonst stürzt das Panel ab.

Ergebnisse #

Alle folgenden Zahlen sind Mediane aus drei Durchläufen; die Rohberichte jedes Durchlaufs liegen im Repository. Zur Reproduzierbarkeit: In den Profilen baseline, load und max-throughput weicht die Median-Latenz zwischen den Durchläufen um höchstens 6,1 % ab, der RPS um höchstens 2,7 %. smoke ist zu kurz (28–34 Anfragen pro Durchlauf), sodass die Streuung seines Medians 22 % erreicht. In den Stress-Profilen ist das Verhalten erwartungsgemäß weniger stabil: Der stress-1200-Median von GameAP 4 über die Durchläufe lag beispielsweise bei 23,7 / 24,6 / 31,9 ms.

Latenz nach Laststufe #

Median-Latenz, ms:

95. Perzentil, ms:

Was das zeigt.

Bis einschließlich 100 VUs antworten alle fünf Panels ohne einen einzigen Fehler, und die einzige Frage ist die Geschwindigkeit: Die Go-Panels bleiben bei einem Median unter 2 ms, GameAP 3 bei rund 9 ms, Pterodactyl bei 13–21 ms, Pelican bei 16–55 ms. Pelicans Median steigt bereits im load-Profil (54,5 ms, p95 — 473 ms): Wie der Ressourcen-Abschnitt zeigen wird, ist ihm bei 100 VUs praktisch die CPU ausgegangen.

In den Stress-Profilen laufen die Gruppen radikal auseinander. GameAP 4 besteht 800 und 1000 VUs ohne Median-Degradation (0,6–0,8 ms), PufferPanel verlangsamt sich bei 1000 VUs auf 114 ms und beginnt, Fehler zurückzugeben, GameAP 3 hält 800 VUs bei einem Median von 28 ms (p95 — 0,9 s) und geht jenseits von 1000 auf 1,5–2 s über. Pterodactyl und Pelican antworten bereits bei 800 VUs in Sekunden und bei 1000–1200 in 8–13 s (Median).

Beachtenswert ist die Kluft zwischen Median und p95 bei den PHP-Panels schon bei niedriger Last: Pterodactyls baseline-Median liegt bei 12,7 ms, sein p95 jedoch bei 79 ms. Ihr Schweif langsamer Antworten ist auch dort lang, wo das Panel insgesamt mithält.

Durchsatzgrenze #

Das max-throughput-Profil: 100 VUs führen dieselben drei Anfragen ohne Pausen aus — 30 s Ramp-up, 2 min Haltephase, 10 s Ramp-down. Der RPS wird als Durchschnitt über das gesamte Fenster berechnet, Rampen eingeschlossen.

Kein einziges Panel gab auch nur einen Fehler zurück — und doch unterscheidet sich der Durchsatz der Extreme um den Faktor 15 (1126 gegenüber 76 Anfragen/s). Dem sollte man die CPU-Auslastung gegenüberstellen: In diesem Profil läuft jedes Panel an seiner Grenze (95–100 % der CPU der VM — siehe die Ressourcen-Tabelle). Gleiche Auslastung, um Vielfaches auseinanderliegende Ergebnisse: Panels nach „CPU-Last“ zu vergleichen, ist sinnlos; entscheidend ist, wie viel Arbeit ein Panel pro Kern erledigt.

Verhalten unter Überlast #

Fehlgeschlagene Anfragen (HTTP ≥ 400), % aller Anfragen im Profil:

Die Bruchpunkte diesen Daten zufolge: PufferPanel liefert als Erstes Fehler: vereinzelte (0,08–0,12 %) bereits bei 800 VUs, 21 % bei 1000, 35 % bei 1200 (bis zu 40 % bei der Listen-Anfrage). GameAP 4 besteht 1000 VUs nahezu fehlerfrei (Median — null Fehler; 0,011 % in einem der drei Durchläufe) und gibt bei 1200 VUs 14,3–15,5 % Fehler zurück. Die PHP-Panels geben überhaupt keine Fehler zurück — in keinem Profil.

Aber „0 % Fehler“ bedeutet hier nicht „das Panel funktioniert“. Bei stress-1200 liegt der p95 von GameAP 3 bei 2,1 s, der von Pterodactyl bei 14,1 s, der von Pelican bei 17,5 s. Formal bekommt jede Anfrage irgendwann ein 200 (k6 wartet bis zu 60 s); praktisch ist ein Panel, das in 10–17 Sekunden antwortet, unbrauchbar. Das sind zwei verschiedene Degradationsmodi, nicht „PHP hält durch und Go nicht“:

• Go-Panels — Fail-Fast: Ein Teil der Anfragen endet schnell mit einem Fehler, der Rest wird mit akzeptabler Latenz bedient (der Median von GameAP 4 bei 1200 VUs liegt bei 25 ms, der von PufferPanel bei 97 ms). Der Client weiß sofort, dass der Server kämpft.
• PHP-Panels — eine Warteschlange: PHP-FPM reiht die Anfragen in eine Queue ein, es gibt keine Fehler, aber die Antwortzeit wächst grenzenlos. Der Client wartet, ohne zu wissen, ob eine Antwort kommt.

Welcher Modus der „richtige“ ist, ist eine Frage der Anforderungen, nicht des Benchmarks. Die praktische Konsequenz ist eindeutig: Die Überlast eines PHP-Panels taucht im Fehler-Monitoring nicht auf — nur in der Latenz.

Erreichte RPS in den Stress-Profilen:

Diese Tabelle bitte genau lesen: Wegen der Think-Time-Pausen und der allmählichen VU-Rampe kann das Stress-Profil physikalisch nicht mehr als ~260 Anfragen/s liefern (die zeitgemittelte Zahl aktiver VUs beträgt ≈ 268, bei ~3,1 s Pausen pro Drei-Anfragen-Iteration). GameAP 4 und PufferPanel stoßen an die Grenze des Profils, nicht an ihre eigene: 259 und 257. GameAP 3 schafft 210. Pterodactyl und Pelican hingegen liefern in jedem Stress-Profil ungefähr ihren max-throughput (82–90 bzw. 68–74 Anfragen/s gegenüber Grenzen von 93 und 76) — das Panel bedient, was es kann, der Rest staut sich in der Warteschlange.

Ressourcen und Engpässe #

CPU-Spitzenwert der Panel-VM, %:

Die Schlüsselzeile ist load: Die „Arbeitslast“ von 100 gleichzeitigen Nutzern, die jedes Panel mit null Fehlern besteht, kostet GameAP 4 und PufferPanel 2–4 % CPU, GameAP 3 — 26 %, Pterodactyl — 81 %, Pelican — 97 %. Pterodactyl und Pelican laufen in diesem Profil bereits am Rand der Sättigung — für Lastspitzen bleibt ihnen kein Puffer.

Wohin die CPU unter Überlast fließt — Prozesse im Stress-Profil (800 VUs), Spitzenwert über das Fenster, Mittelwert der Durchläufe 2–3:

100 % = ein Kern, insgesamt 4 vCPU. Nginx blieb in jedem Durchlauf ≤ 3,2 %; Redis, wo process_exporter es sah, ≤ 5,1 % (die Monitoring-Abdeckung des Redis-Prozesses erwies sich als lückenhaft — in manchen Durchläufen verfolgte process_exporter ihn nicht; das ändert nichts am Gesamtbild, aber er bleibt aus der Tabelle ausgenommen).

Die interessanteste Zeile ist die der Datenbank. Bei Pterodactyl und Pelican verbraucht MySQL 94–109 % CPU — nahezu einen ganzen Kern — und bedient dabei 68–82 Anfragen pro Sekunde. Bei GameAP 3 ist dasselbe MySQL 8.0 mit denselben Einstellungen zu 31 % ausgelastet — bei 210 Anfragen pro Sekunde. Pro Anfrage verbrennen Pterodactyl und Pelican etwa neunmal mehr Datenbank-CPU-Zeit als GameAP 3. Offenbar ist der Engpass dieser Panels nicht PHP als solches, sondern ihre Datenbank-Workload. Die Ursache wurde nicht profiliert und bleibt eine offene Frage; ein EXPLAIN-Durchgang über die Abfragen der Listen-Endpunkte liegt nahe.

RAM-Spitzenwert der VM, MB:

Prozess-RSS bei stress-800 (Mittelwert der Durchläufe 2–3): die Anwendung — 65 MB bei GameAP 4 und 107 MB bei PufferPanel gegenüber 2,7–4,2 GB Gesamt-RSS über fünfzig php-fpm-Worker; die Datenbank — 107 MB PostgreSQL bei GameAP 4 gegenüber ~613–641 MB MySQL. Zwei Vorbehalte: Der RSS der php-fpm-Worker zählt Shared Memory mehrfach (der reale Verbrauch der VM steht in der Tabelle oben), und PufferPanels PostgreSQL-RSS schwankte spürbar zwischen den Durchläufen (721 MB im ersten, ~440 MB im zweiten und dritten).

Und eine Anomalie, die ehrlicherweise unerklärt bleibt: PufferPanel ist das einzige Panel, das unter Last aktiv auf die Festplatte schreibt — Spitzen von 140–150 Schreib-IOPS gegenüber 4 bei GameAP 4 und 21–24 bei den übrigen. Die Ursache (Logs? Auditing? Besonderheiten der PostgreSQL-Nutzung?) wurde nicht untersucht.

Was die einzelnen Endpunkte zeigen #

Median-Latenz pro Endpunkt im load-Profil, ms:

Die Serverliste ist die schwerste Anfrage bei jedem Panel, aber bei Pterodactyl und Pelican ist die Kluft dramatisch: Die Liste ist 7–8-mal langsamer als die Details-Anfrage (87 und 141 ms gegenüber 13 und 26 ms). Es ist die Listen-Anfrage, die unter Last als Erstes degradiert.

Zur Erinnerung an den Vorbehalt aus der Methodik: Die Größe der Listen-Antwort unterscheidet sich zwischen den Panels (102 Datensätze bei GameAP, 50 bei Pterodactyl/Pelican, 20 bei PufferPanel), daher ist ein Vergleich der list_servers-Zeile zwischen den Panels nicht fair. Was man aus dieser Tabelle ablesen kann, ist das Verhältnis zwischen den Endpunkten innerhalb eines Panels — und die Tatsache, dass GameAP 4 seine vollständige Liste von 102 Datensätzen (~13 KB) schneller liefert, als irgendein PHP-Panel seine erste Seite liefert.

Die drei Direktvergleiche #

GameAP 3 → GameAP 4. Dafür wurde neu geschrieben: Der baseline-Median ist 9,24 gegenüber 0,82 ms (11×), der load-Median 8,78 gegenüber 0,59 ms (15×), die Durchsatzgrenze 394 gegenüber 1126 Anfragen/s (2,9×), der Speicher der gesamten VM 1,0–1,4 GB gegenüber 0,45–0,70 GB, die CPU im load-Profil 26 % gegenüber 2,4 %.

GameAP 4 vs. PufferPanel. Beide sind Go + PostgreSQL, und beide sind eine Größenordnung schneller als die PHP-Gruppe. Zwischen den beiden: GameAP 4 ist nach Median in baseline/load 1,9–2,3× schneller und nach Durchsatzgrenze 1,6× (1126 gegenüber 696), bricht unter Überlast später ein (15 % Fehler bei 1200 VUs gegenüber PufferPanels 21 % bereits bei 1000 und ersten vereinzelten Fehlern bei 800) und rührt die Festplatte kaum an. Beachten Sie jedoch, dass PufferPanel in diesem Szenario eine Größenordnung weniger Daten pro Listen-Anfrage liefert (20 Datensätze, ~1,6 KB gegenüber 102 Datensätzen, ~13 KB) — der Abstand wurde bei einer für PufferPanel leichteren Arbeit gemessen.

Pterodactyl vs. Pelican. Der Fork erwies sich in jedem Profil als langsamer als das Original: Im load-Profil ist der Median 54,5 gegenüber 20,7 ms, p95 — 473 gegenüber 154 ms, die Grenze — 76 gegenüber 93 Anfragen/s, und die CPU-Sättigung tritt früher ein (97 % bereits bei load gegenüber 81 %). Prozessbezogen ist Pelicans php-fpm stärker ausgelastet (260 gegenüber 243 %) und sein MySQL weniger (94 gegenüber 109 %). Die Ursachen der Unterschiede wurden nicht untersucht; zum Testzeitpunkt war Pelican ein junger Fork (1.0.x), und sein Performance-Profil kann sich noch ändern.

Einschränkungen #

Eine Aufstellung dessen, was die Schlussfolgerungen dieses Tests begrenzt.

1. Unterschiedliche Datenbanken zwischen den Gruppen. Die Go-Panels liefen auf PostgreSQL, die PHP-Panels auf MySQL 8.0 (in beiden Fällen die von den Entwicklern der Panels empfohlenen Konfigurationen). Jeder „Go vs. PHP“-Vergleich hier bedeutet in Wirklichkeit „Go+PostgreSQL vs. PHP+MySQL“ — dieser Test trennt den Beitrag der Datenbank nicht von dem der Sprache und der Architektur. Innerhalb jeder Gruppe sind die Datenbanken identisch.
2. Unterschiedliche Antwortgrößen bei list_servers. Jede Datenbank enthält 100 Server, aber GameAP liefert die ganze Liste (102 Datensätze), Pterodactyl/Pelican die erste Seite von 50, PufferPanel die erste Seite von 20; die Antwortgrößen reichen von 1,6 bis 16 KB. Der Test hat die Paginierung nicht auf eine gemeinsame Seitengröße normalisiert. Direkte panelübergreifende Listen-Latenzvergleiche sind daher verzerrt; zugunsten wessen, hängt vom Paar ab (die Verzerrung macht PufferPanels Arbeit leichter und die von GameAP schwerer).
3. GameAP 3 hat keinen Status-Endpunkt: Sein server_status ist eine Wiederholung der Details-Anfrage, sodass ein Drittel des Szenarios bei GameAP 3 nicht äquivalent zu den anderen Panels ist.
4. Nur lesend, nur API. Keine Schreibzugriffe, kein WebSocket, keine UI; die Mock-Server wurden nie installiert oder gestartet, und die Daemons auf den benachbarten VMs waren praktisch untätig. Dies ist ein Test der HTTP/API-Schicht der Panels, nicht der Panels als Ganzes.
5. Das Closed-Loop-Modell von k6 (siehe Methodik): Die degradierten Panels erhielten automatisch weniger Last, daher sind ihre Stress-Zahlen eine optimistische Schätzung. Das k6-Anfragen-Timeout beträgt 60 s.
6. Aufwärmphase. Ein smoke-Aufwärmdurchlauf (30 s) vor der Profilserie und ein Dienst-Neustart vor jedem Profil. Bei den Panels, die nicht CPU-limitiert sind (GameAP 3/4, PufferPanel), ist die durchschnittliche Latenz bei baseline höher als im schwereren load-Profil (0,85 → 0,66 ms; 1,49 → 1,27; 10,9 → 9,7) — ein Teil des baseline-Fensters ist offenbar noch Aufwärmphase. Das ändert nichts an den Schlussfolgerungen, aber die absoluten baseline-Zahlen sind leicht aufgebläht.
7. Neustart-Asymmetrie. Vor jedem Profil wurden bei den PHP-Panels php-fpm, nginx und MySQL neu gestartet (Buffer Pool und Caches geleert; bei GameAP 3 auch Redis), bei PufferPanel die Anwendung (PostgreSQL lief weiter), und bei GameAP 4 nur nginx (die Anwendung und PostgreSQL nicht). Die PHP-Panels starteten jedes Profil „kälter“. Die Rampenphasen der Profile kompensieren das teilweise, aber die Asymmetrie wurde nicht vollständig beseitigt.
8. Versionen auf Major-Ebene erfasst (GameAP 4.x / 3.x, Pterodactyl 1.11.x, Pelican 1.0.x, PufferPanel 3.x, April 2026). GameAP 4 ist funktional jünger und einfacher als die übrigen — weniger Arbeit pro Anfrage zu leisten kann Teil seines Vorteils sein; das wurde nicht quantifiziert.
9. Veränderte Limits. Bei Pterodactyl und Pelican wurden die Rate-Limits auf 10 000 Anfragen/min angehoben — eine Standardinstallation hätte die Last früher abgeschnitten.
10. Monitoring. CPU und RAM sind VM-weite Metriken im 15-s-Schritt (kurze Spitzen können geglättet werden); Prozessmetriken haben einen 30-s-Schritt, und die Abdeckung des Redis-Prozesses ist über die Durchläufe lückenhaft; PufferPanels smoke-Statistiken enthalten die OAuth-Anfrage aus setup(). Eine Hardware-Konfiguration, ein VM-Layout, 100 Server in der Datenbank — auf anderer Hardware und bei anderen Datenmengen werden die absoluten Zahlen anders ausfallen.

Fazit #

Zurück zu den drei Fragen aus den Zielen.

Wie unterschiedlich sind die Panels bei normaler Last? Im load-Profil (bis zu 100 gleichzeitige Nutzer) arbeiten alle fünf Panels mit null Fehlern, und die Latenz unterscheidet sich um eine Größenordnung oder mehr: 0,6–1,4 ms Median bei den Go-Panels, ~9 ms bei GameAP 3, 21–55 ms bei Pterodactyl/Pelican. Sagen wir es unverblümt: Für einen Menschen im Browser sind selbst 55 ms schnell. Wenn Sie ein Panel, ein Dutzend Server und keine Automatisierung betreiben, wird sich jeder der Kandidaten instantan anfühlen. Der Unterschied wird praktisch bei Integrationen und Automatisierung, bei Massenoperationen, auf billiger Hardware — und beim Preis dieser Geschwindigkeit: Dieselben 100 VUs kosten Pelican 97 % CPU und GameAP 4 — 2,4 %.

Wo liegt der Bruchpunkt und wie bricht ein Panel? Nach Durchsatzgrenze: 1126 (GameAP 4) → 696 (PufferPanel) → 394 (GameAP 3) → 93 (Pterodactyl) → 76 (Pelican) Anfragen/s. Unter Überlast gibt es zwei Modi: Die Go-Panels scheitern schnell mit Fehlern (PufferPanel ab 800–1000 VUs, GameAP 4 ab 1200), die PHP-Panels geben keine Fehler zurück, antworten aber in Sekunden bis Dutzenden von Sekunden. Die praktische Lehre für das Monitoring: Die Überlast eines PHP-Panels ist nur in der Latenz sichtbar — Fehler-Alarme wird es nicht geben.

Was ist der Engpass? Bei GameAP 4 — die eigene CPU der Anwendung (die Datenbank ist kaum ausgelastet). Bei PufferPanel — die Anwendung plus nennenswerte Festplattenschreibzugriffe, deren Ursache nicht untersucht wurde. Bei GameAP 3 — php-fpm (318 % CPU bei MySQL mit 31 %). Bei Pterodactyl und Pelican sieht das Bild anders aus: Neben php-fpm frisst MySQL nahezu einen ganzen Kern — pro Anfrage ist das etwa neunmal mehr Datenbank-CPU-Zeit, als GameAP 3 auf dasselbe MySQL verwendet. Das ist das interessanteste Ergebnis des Tests, und es verdient eine eigene Untersuchung mit Query-Profiling.

Dieser Test misst einen einzigen Ausschnitt — die Lesegeschwindigkeit der HTTP/API-Schicht. Er sagt nichts über Funktionsumfang, Bedienbarkeit, Sicherheit oder Ökosystem aus, und die Wahl eines Panels hängt auch davon ab. GameAP 4 hat diesen Benchmark gewonnen, ist aber auch der jüngste Kandidat; Pterodactyl hat nach Zahlen verloren — und bleibt dennoch das verbreitetste Panel mit dem größten Ökosystem. Was Sie mit diesen Fakten anfangen, bleibt Ihnen überlassen.

Wie es weitergeht #

• Phase 2 — Gameserver-Verwaltung: Massenstart/-stopp von N Servern, stationärer Zustand mit laufenden Servern, parallele WebSocket-Konsolen, Server-Erstellung über die API. Dafür wird ein Fake-Gameserver vorbereitet — eine Binärdatei, die einen echten Gameserver nachahmt.
• Skalierung nach Datenvolumen: Durchläufe mit 1 / 100 / 1000 Servern in der Datenbank, um zu messen, wie die Latenz der Listen-Endpunkte von der Datenbankgröße abhängt.
• Offene Fragen aus dieser Phase: PufferPanels Festplattenschreibzugriffe, Profiling der MySQL-Abfragen von Pterodactyl/Pelican, der Unterschied zwischen Pelican und Pterodactyl.

Die Skripte, Konfigurationen und Rohdaten aller Durchläufe liegen im Repository game-panels-benchmark. Wenn Sie einen Fehler in der Methodik oder der Interpretation finden — öffnen Sie ein Issue: Er wird erneut geprüft und eine Korrektur veröffentlicht.