GameAP-Blog

Wie veröffentlichen Sie Ihr Plugin?

Sat, 08 Aug 2026 13:00:00 +0300

GameAP-Plugins werden auf plugins.gameap.dev veröffentlicht — von dort installieren Nutzer sie direkt aus dem Panel. Diese Anleitung führt durch den gesamten Weg: vom Anlegen des Plugin-Eintrags bis zum automatischen Ausliefern neuer Versionen aus CI.

Vorausgesetzt wird, dass Ihr Plugin bereits geschrieben ist und zu einer .wasm gebaut wird. Außerdem brauchen Sie ein Konto auf plugins.gameap.dev: entweder eine normale Registrierung mit E-Mail-Bestätigung oder die Anmeldung über GitHub, GitLab oder Google.

Es gibt zwei Wege, eine Version hochzuladen: manuell über das Dashboard oder über die API aus CI. Beginnen Sie mit dem Dashboard und steigen Sie auf CI um, sobald Ihr Build stabil läuft.

Schritt 1. Ein Entwicklerkonto #

Das Veröffentlichen von Plugins erfordert ein Konto mit Entwicklerstatus. Dieser wird kostenlos und sofort vergeben — Sie müssen lediglich die Veröffentlichungsregeln akzeptieren.

Klicken Sie im Plugin-Marktplatz auf Publish your plugin („Ihr Plugin veröffentlichen“) — die Schaltfläche in der oberen rechten Ecke.

Der Plugin-Marktplatz

Die Seite mit den Veröffentlichungsregeln öffnet sich. Kurz gesagt, wozu Sie sich verpflichten:

Funktionierende, hochwertige Plugins — nur funktionsfähige, getestete Plugins, die das halten, was ihre Beschreibung verspricht.
Kein schädlicher Code — keine Backdoors, versteckten Miner oder verschleierte Logik; jede Erhebung von Nutzerdaten muss klar offengelegt werden.
Rechte und Lizenzierung — Sie besitzen den Code oder dürfen ihn verbreiten, Lizenzen Dritter werden eingehalten, und die Lizenz Ihres Plugins ist angegeben.
GameAP-Kompatibilität — das Plugin funktioniert mit aktuellen Panel-Releases und erfüllt die Anforderungen an das Plugin-Format.
Updates und Support — kritische Fehler und Sicherheitsprobleme werden innerhalb einer angemessenen Frist behoben, und Nutzermeldungen erhalten eine Antwort.
Moderation — jedes Plugin und jede Version wird geprüft, und ein Plugin, das gegen die Regeln verstößt, kann jederzeit entfernt werden.
Kein Spam und keine Duplikate — keine irreführenden Namen, kein Keyword-Stuffing.

Der vollständige Text steht auf der Seite selbst — lesen Sie ihn am besten ganz.

Klicken Sie unten auf Agree („Zustimmen“). Die Rolle wird sofort vergeben, ohne Prüfung und Wartezeit: In der Seitenleiste erscheint der Bereich Developer („Entwickler“) mit Dashboard, My Plugins, New Plugin und Support, und eine E-Mail teilt Ihnen mit, dass Sie nun Entwickler sind.

Hinweis. Die Regeln können nur mit einer bestätigten E-Mail-Adresse akzeptiert werden: Andernfalls bleibt die Schaltfläche Agree deaktiviert, und die Seite zeigt eine Erinnerung, Ihre Adresse zu bestätigen. Konten, die über GitHub, GitLab oder Google erstellt wurden, gelten sofort als bestätigt.

Die Schaltfläche Publish your plugin ist für alle sichtbar, auch für Besucher, die nicht angemeldet sind. Ohne Sitzung zeigt die Regelseite stattdessen Log in to agree („Anmelden, um zuzustimmen“) — nach der Anmeldung kehren Sie zu den Regeln zurück.

Schritt 2. Das Plugin anlegen #

Wählen Sie im linken Menü New Plugin („Neues Plugin“) — das Erstellungsformular öffnet sich.

Ein neues Plugin anlegen

Feld	Pflicht	Was gehört hinein
Name	ja	Bis zu 255 Zeichen
Summary	ja	Ein einziger Satz für die Katalogkarte, bis zu 500 Zeichen
Description	ja	Vollständige Beschreibung in Markdown — das Feld hat eine Formatierungs-Symbolleiste
Category	nein	Eine der drei unten
Labels	nein	Stichwörter, über die sich das Plugin leichter finden lässt
License	nein	Freier Text: `MIT`, `GPL-3.0`, `Proprietary`
Source URL	nein	Link zu den Quellen, falls sie offen sind
Repository URL	nein	Link zum Repository
Homepage URL	nein	Website des Plugins oder des Autors

Die Kategorien:

Server Management („Serververwaltung“) — die meisten Plugins. Alles, was Aktionen auf einem Gameserver hinzufügt.
Files („Dateien“) — Erweiterungen des Dateimanagers: Editoren, Viewer für bestimmte Formate.
Integrations („Integrationen“) — Plugins, die die Möglichkeiten des Panels wesentlich erweitern, etwa die Datenbankverwaltung.

Das Icon kann in diesem Schritt noch nicht hochgeladen werden — das Formular weist ausdrücklich darauf hin; der Uploader erscheint direkt nach dem Anlegen.

Hinweis. Source URL und Repository URL wirken sich auf mehr als den Eintrag aus. Wenn keines der beiden Felder ausgefüllt ist, muss jede Version ein Quellarchiv mitbringen — die Moderatoren brauchen etwas, gegen das sie den Build prüfen können. Füllen Sie mindestens eines der Felder aus, wenn Ihre Quellen öffentlich sind.

Schritt 3. Die Plugin-ID #

Nach dem Klick auf Create („Anlegen“) landen Sie auf der Bearbeitungsseite des Plugins. Ihr erster Block ist die Plugin ID — ein schreibgeschütztes Feld mit einer Kopierschaltfläche.

Diese ID muss in den Quellcode Ihres Plugins eingetragen werden — in das id-Feld der PluginInfo-Struct, die GetInfo zurückgibt. So ordnet das Panel ein installiertes Plugin seinem Marktplatz-Eintrag zu.

Die ID wird einmalig beim Anlegen erzeugt und kann nicht geändert werden. Im Kern ist sie eine 64-Bit-Zahl (8 zufällige Bytes) in Base32-Schreibweise — 13 lateinische Buchstaben und Ziffern, zum Beispiel fmqnme42gg7da. Dieselbe ID taucht in der URL der Plugin-Seite und in der Adresse des CI-Endpunkts auf.

Wie das in bestehenden Plugins aussieht:

plugin-mysql — die Konstante PLUGIN_ID (fmqnme42gg7da)
plugin-goldsrc-addons — PLUGIN_ID (ezvdsxmlu6fbk)
plugin-minecraft-modrinth — PLUGIN_ID (dshdabjp2l73a)

Hinweis. Tragen Sie die ID ein und bauen Sie die .wasm neu, bevor Sie die erste Version hochladen. Versionen sind unveränderlich: Sie können eine Datei nicht unter derselben Nummer erneut hochladen — Sie müssten die Versionsnummer erhöhen.

Schritt 4. Icon und Übersetzungen #

Dieselbe Bearbeitungsseite enthält einen Icon-Uploader: JPG, PNG, WebP oder SVG, bis zu 2 MB, empfohlen 128×128.

Die Plugin-Seite hat einen Block Translations („Übersetzungen“). Der Katalog ist zweisprachig, und jeder Besucher sieht den Eintrag in seiner eigenen Sprache: Ohne Übersetzung bekommt ein russischer Nutzer die englische Beschreibung und umgekehrt. Name, Kurzbeschreibung und Beschreibung werden pro Sprache separat übersetzt — fünf Minuten Arbeit, die den Eintrag spürbar besser lesen lassen.

Schritt 5. Eine Version hochladen #

Suchen Sie auf der Plugin-Seite die Karte Versions („Versionen“) und klicken Sie auf Upload Version („Version hochladen“).

Eine neue Version hochladen

Feld	Pflicht	Was gehört hinein
Version	ja	Semantische Version: `1.0.0`, `1.2.0-beta.1`
Plugin File	ja	Die kompilierte `.wasm`, bis zu 100 MB
GPG Signature	nein	Abgetrennte Signatur `.sig` oder `.asc`, bis zu 1 MB
Source Code Archive	abhängig	`.zip` oder `.tar.gz`, bis zu 50 MB
Changelog	nein	Was sich seit der vorherigen Version geändert hat, in Markdown
Stable Release	—	Ein Schalter, standardmäßig aktiviert
Min GameAP Version	nein	Die Panel-Version, ab der Ihr Plugin funktioniert

Die GPG-Signatur ist optional, aber willkommen: Der Server speichert sie unverändert und verifiziert sie nie — sie existiert, damit Nutzer die Authentizität der Datei selbst prüfen können.

Das Quellcode-Archiv ist Pflicht, wenn beim Plugin weder Source URL noch Repository URL ausgefüllt sind — das Formular ändert die Feldbezeichnung dann selbstständig von „(Optional)“ zu „(Required)“. Das Archiv wird nur für Moderation und Build-Verifikation verwendet; es wird nie veröffentlicht und ist über keinen öffentlichen Endpunkt erreichbar.

Hinweis. Eine über das Dashboard hochgeladene Version bleibt ein Entwurf. Bis Sie sie zur Prüfung einreichen, sieht sie niemand.

Screenshots der Version #

Direkt nach dem Upload öffnet sich ein zweiter Schritt — Add Screenshots („Screenshots hinzufügen“). Screenshots gehören zu einer bestimmten Version: JPG, PNG oder WebP, bis zu 10 Stück, jeweils 5 MB. Der Schritt kann übersprungen und später von der Versionsseite aus nachgeholt werden.

Schritt 6. Zur Prüfung einreichen #

Plugins durchlaufen eine Moderation — anhand genau der Veröffentlichungsregeln, die Sie in Schritt 1 akzeptiert haben. Im Kopfbereich der Plugin-Seite gibt es die Schaltfläche Submit for Review („Zur Prüfung einreichen“) — sie ist nur sichtbar, solange das Plugin den Status Draft oder Rejected hat.

Ein Plugin ohne Versionen kann nicht eingereicht werden — laden Sie zuerst eine Version hoch. Das Einreichen einer Version über die Versionstabelle versetzt auch das Plugin selbst von Draft zu Pending Review, sodass die Schaltfläche im Kopfbereich in der Regel nicht separat gebraucht wird.

Status	Bedeutung	Was Sie tun können
Draft	Angelegt, nirgendwo eingereicht	Bearbeiten, zur Prüfung einreichen, löschen
Pending Review	Wartet auf einen Moderator	Warten
Rejected	Ein Moderator hat es zurückgeschickt	Korrigieren und erneut einreichen
Released	Für alle im Katalog verfügbar	Neue Versionen hochladen
Approved	Ein Zwischenstatus im Datenmodell	—
Deprecated	Als veraltet markiert	Weiterhin installierbar, aber gekennzeichnet
Retracted	Von der Veröffentlichung zurückgezogen	Nicht zur Installation verfügbar

Nach der Freigabe wechseln Plugin und Version direkt zu Released. Öffentlich sichtbar sind nur Objekte in diesem Status: Wenn ein Plugin veröffentlicht ist, seine einzige Version aber noch in der Prüfung, gibt es nichts zu installieren.

Der Ablehnungsgrund kommt per E-Mail — die Plugin-Seite zeigt nur den Status, also prüfen Sie Ihren Posteingang.

Deploy-Tokens #

Um Versionen aus CI zu veröffentlichen, brauchen Sie ein Deploy-Token. Es befindet sich ganz unten auf der Plugin-Seite, in der Karte Deploy Tokens.

Die Karte mit den Deploy-Tokens

Klicken Sie auf Create Token („Token erstellen“) und füllen Sie den Dialog aus: einen Namen (zum Beispiel GitHub Actions) und optional ein Ablaufdatum.

Ein Deploy-Token erstellen

Hinweis. Das Token wird genau einmal angezeigt, direkt nach dem Erstellen. Auf dem Server wird nur sein Hash gespeichert, der Wert lässt sich nicht wiederherstellen — kopieren Sie es direkt in Ihre CI-Secrets.

Was Sie über Tokens wissen sollten:

Ein Token ist an ein Plugin gebunden und kann nur dessen Versionen hochladen. Es öffnet weder andere Plugins noch den Rest der API.
Das Format ist gapd_ plus 43 Zeichen, insgesamt 48. Das Präfix ist für Secret-Scanner leicht zu erkennen.
Die Tabelle zeigt das Token-Präfix, das Erstellungsdatum, die letzte Verwendung und das Ablaufdatum — praktisch, um herauszufinden, welches Token noch in Gebrauch ist.
Der Widerruf wirkt sofort: Eine Pipeline mit einem widerrufenen Token schlägt beim nächsten Lauf fehl.
Ein einzelnes Plugin kann bis zu 20 Tokens haben.

Aus CI veröffentlichen #

Der CI-Endpunkt nimmt eine neue Version ohne interaktiven Login entgegen — er authentifiziert sich mit einem Deploy-Token.

Hochladen mit curl #

curl --fail-with-body -sS \
 -H "Authorization: Bearer $GAMEAP_DEPLOY_TOKEN" \
 -F "version=1.2.3" \
 -F "file=@build/plugin.wasm" \
 -F "signature=@build/plugin.wasm.asc" \
 -F "changelog=Absturz beim Serverneustart behoben" \
 -F "min_gameap_version=4.1.0" \
 -F "is_stable=true" \
 "https://plugins.gameap.dev/api/ci/plugins/$GAMEAP_PLUGIN_ID/versions"

Die Anfrage ist ein POST mit multipart/form-data. Die Formularfelder:

Feld	Pflicht	Beschreibung
`version`	ja	Semantische Version, z. B. `1.2.3`
`file`	ja	Die kompilierte `.wasm`, bis zu 100 MB
`signature`	nein	Abgetrennte GPG-Signatur, bis zu 1 MB
`source`	abhängig	Quellarchiv `.zip`/`.tar.gz` bis 50 MB; Pflicht, wenn das Plugin weder Source URL noch Repository URL hat
`changelog`	nein	Release-Notes; praktisch aus einer Datei: `-F "changelog=<CHANGELOG.md"`
`min_gameap_version`	nein	Minimale GameAP-Version
`min_plugin_api_version`	nein	Minimale Plugin-API-Version (das Dashboard-Formular hat dieses Feld nicht)
`is_stable`	nein	`true` oder `1` markiert die Version als stabil
`submit`	nein	Standardmäßig `true`; `false` belässt die Version als Entwurf

Setzen Sie keinen Schrägstrich ans Ende der URL. Der Router beantwortet .../versions/ mit einem 301, und curl wiederholt den POST-Body bei einem Redirect nicht — der Upload würde still zu einem GET.

Eine erfolgreiche Antwort ist ein 201 mit einem Body wie:

{
 "id": 123,
 "plugin_id": "fmqnme42gg7da",
 "version": "1.2.3",
 "file_size": 1048576,
 "file_hash": "9f86d081884c7d65...",
 "has_source": false,
 "status": "pending_review"
}

GitHub Actions #

Dieser Workflow wird ausgelöst, wenn ein GitHub-Release veröffentlicht wird, baut das Plugin, signiert es — sofern ein GPG-Schlüssel in den Secrets konfiguriert ist — und lädt es zu plugins.gameap.dev hoch. Der Release-Text wird zum Changelog, und die Version wird nur dann als stabil markiert, wenn das Release kein Pre-Release ist.

name: Publish plugin

on:
 release:
 types: [published]

jobs:
 publish:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4

 - name: Build plugin
 run: make wasm  # muss build/plugin.wasm erzeugen

 - name: Sign plugin
 if: env.GPG_SIGNING_KEY != ''
 env:
 GPG_SIGNING_KEY: ${{ secrets.GPG_SIGNING_KEY }}
 GPG_PASSPHRASE: ${{ secrets.GPG_PASSPHRASE }}
 run: |
 printf '%s' "$GPG_SIGNING_KEY" | gpg --batch --import
 printf '%s' "$GPG_PASSPHRASE" | gpg --batch --yes \
 --pinentry-mode loopback --passphrase-fd 0 \
 --detach-sign --armor \
 -o build/plugin.wasm.asc build/plugin.wasm

 - name: Publish to plugins.gameap.dev
 env:
 GAMEAP_DEPLOY_TOKEN: ${{ secrets.GAMEAP_DEPLOY_TOKEN }}
 GAMEAP_PLUGIN_ID: ${{ vars.GAMEAP_PLUGIN_ID }}
 TAG: ${{ github.event.release.tag_name }}
 RELEASE_BODY: ${{ github.event.release.body }}
 PRERELEASE: ${{ github.event.release.prerelease }}
 run: |
 VERSION="${TAG#v}"
 printf '%s' "$RELEASE_BODY" > "$RUNNER_TEMP/changelog.md"
 ARGS=(--fail-with-body -sS
 -H "Authorization: Bearer ${GAMEAP_DEPLOY_TOKEN}"
 -F "version=${VERSION}"
 -F "file=@build/plugin.wasm"
 -F "changelog=<${RUNNER_TEMP}/changelog.md")
 # Signatur nur anhängen, wenn der Sign-Schritt sie erzeugt hat
 if [ -f build/plugin.wasm.asc ]; then
 ARGS+=(-F "signature=@build/plugin.wasm.asc")
 fi
 if [ "$PRERELEASE" != "true" ]; then
 ARGS+=(-F "is_stable=true")
 else
 ARGS+=(-F "is_stable=false")
 fi
 curl "${ARGS[@]}" \
 "https://plugins.gameap.dev/api/ci/plugins/${GAMEAP_PLUGIN_ID}/versions"

VERSION="${TAG#v}" entfernt das führende v, sodass das Tag v1.2.3 als Version 1.2.3 veröffentlicht wird.

Die produktive Variante dieses Workflows — mit Frontend-Build, Cargo-Cache und HTTP-Statusprüfung — liegt in plugin-mysql.

Das GitHub-Repository konfigurieren #

Token und Plugin-ID gehören nicht in den Code — sie gehören in die Repository-Einstellungen. Öffnen Sie Settings → Secrets and variables (unter Security and quality) → Actions.

Der Einstellungsbereich des Repositorys

Klicken Sie auf dem Tab Secrets auf New repository secret und fügen Sie hinzu:

Name	Wert
`GAMEAP_DEPLOY_TOKEN`	Das Deploy-Token, das Sie beim Erstellen kopiert haben (beginnt mit `gapd_`)
`GPG_SIGNING_KEY`	Ein privater GPG-Schlüssel im ASCII-Armor-Format, falls Sie Ihre Builds signieren
`GPG_PASSPHRASE`	Die Passphrase des GPG-Schlüssels, falls dieser geschützt ist

Repository-Secrets

Auf dem Tab Variables klicken Sie auf New repository variable und fügen Sie hinzu:

Name	Wert
`GAMEAP_PLUGIN_ID`	Die Plugin-ID, z. B. `fmqnme42gg7da`

Repository-Variablen

Die Plugin-ID ist derselbe Base32-Bezeichner, den Sie in PluginInfo eingetragen haben. Kopieren Sie ihn mit der Schaltfläche neben dem Feld Plugin ID auf der Bearbeitungsseite oder aus dem Block Details auf der Plugin-Seite.

Die ID liegt absichtlich in den Variablen und nicht in den Secrets: Sie ist kein Geheimnis, und wenn sie in den CI-Logs sichtbar ist, lassen sich Fehler deutlich leichter diagnostizieren. Das Token hingegen ist immer ein Secret.

So exportieren Sie einen privaten GPG-Schlüssel für GPG_SIGNING_KEY:

gpg --armor --export-secret-keys IHRE_KEY_ID

Veröffentlichen Sie den öffentlichen Schlüssel dort, wo Nutzer ihn finden können — etwa im README des Plugins —, damit die Signatur überprüfbar ist.

Dashboard und CI: unterschiedliche Vorgaben #

Was	Dashboard	CI
Stabiles Release	Der Schalter ist standardmäßig aktiviert	`is_stable` ist standardmäßig false — explizit übergeben
Einreichen zur Prüfung	Manuell, per Schaltfläche	`submit` ist standardmäßig true — die Version geht sofort in die Prüfung
Screenshots	Werden direkt nach dem Upload angeboten	Nicht unterstützt, fügen Sie sie über das Dashboard hinzu

Wenn CI nur die Datei hochladen und Sie die Metadaten von Hand nachpflegen wollen, übergeben Sie submit=false, und die Version bleibt ein Entwurf.

Fehler #

Code	Ursache
`400`	Ungültige Plugin-ID, ein fehlerhafter Multipart-Body oder kein `file` übergeben
`401`	Das Token fehlt, ist ungültig oder abgelaufen; der Header hat nicht die Form `Bearer gapd_...`
`403`	Das Token ist gültig, wurde aber für ein anderes Plugin ausgestellt
`409`	Eine Version mit dieser Nummer existiert bereits
`422`	Die Version besteht die Semver-Prüfung nicht; das Quellarchiv fehlt, ist zu groß oder kein `.zip`/`.tar.gz`; die Größenlimits für Datei oder Signatur sind überschritten

Fehler-Bodies haben eine einheitliche Form:

{
 "status": "error",
 "error": "version already exists",
 "message": "version already exists",
 "http_code": 409
}

Wiederholen Sie den Upload nach einem 5xx-Fehler nicht blind. Das Schreiben der Version und ihr Einreichen zur Prüfung sind keine einzelne Transaktion: Die Version kann bereits existieren, und ein erneuter Versuch liefert 409. Öffnen Sie das Dashboard und prüfen Sie, was tatsächlich passiert ist.

Versionen aktualisieren und zurückziehen #

Eine neue Version wird genau wie die erste hochgeladen — über das Dashboard oder aus CI. Bereits hochgeladene Versionen sind unveränderlich: Eine Datei unter derselben Nummer erneut hochzuladen ist nicht möglich, der Versuch liefert 409. War der Build falsch, erhöhen Sie die Patch-Version.

Jede Zeile der Versionstabelle hat eigene Aktionen:

Edit („Bearbeiten“) — Changelog und Metadaten ändern.
Submit for Review („Zur Prüfung einreichen“) — für Entwürfe und abgelehnte Versionen.
Deprecate („Als veraltet markieren“) — für veröffentlichte Versionen. Die Version bleibt verfügbar, wird aber als veraltet gekennzeichnet.
Retract („Zurückziehen“) — für veröffentlichte und veraltete Versionen. Die Version wird von der Veröffentlichung zurückgezogen.

Nur ein Plugin im Status Draft kann gelöscht werden. Ein veröffentlichtes Plugin lässt sich nicht entfernen — es kann zurückgezogen werden.

Checkliste #

Die E-Mail ist bestätigt, die Veröffentlichungsregeln sind akzeptiert, und das Konto hat Entwicklerstatus.
Das Plugin ist angelegt, und Name sowie beide Beschreibungen sind ausgefüllt.
Source URL oder Repository URL ist ausgefüllt — sonst braucht jede Version ein Quellarchiv.
Die Plugin-ID steht in PluginInfo.id, und die .wasm wurde danach neu gebaut.
Das Icon ist hochgeladen, und die Übersetzungen des Eintrags sind gepflegt.
Die Version ist hochgeladen, optional ergänzt um Signatur und Screenshots.
Die Version ist zur Prüfung eingereicht, nicht als Entwurf liegen geblieben.
Für CI: Ein Deploy-Token ist erstellt und in den Secrets hinterlegt, die Plugin-ID steht in den Variablen.
Der Workflow hat keinen Schrägstrich am Ende der URL und übergibt is_stable explizit.
Nach dem Release ist bestätigt, dass Plugin und Version den Status Released haben.

Lasttests von Gameserver-Verwaltungspanels

Mon, 03 Aug 2026 13:00:00 +0300

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 #

Den Bruchpunkt finden: die Grenze, bis zu der ein Panel noch ordnungsgemäß funktioniert.
Die Alternativen unter möglichst ähnlichen Bedingungen vergleichen.
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:

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

Die Panels #

Panel	Version	Stack	Datenbank	Daemon
GameAP 4.x	4.x	Go	PostgreSQL	gameap-daemon
PufferPanel	3.x	Go	PostgreSQL	integriert
GameAP 3.x	3.x	PHP 8.4 / Laravel	MySQL 8.0	gameap-daemon
Pterodactyl	1.11.x	PHP 8.4 / Laravel	MySQL 8.0	Wings (Docker)
Pelican	1.0.x	PHP 8.4 / Laravel, Pterodactyl-Fork	MySQL 8.0	Wings (Docker)

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 #

VM	vCPU	RAM	Festplatte	Rolle
Panel	4	8 GB	40 GB	Verwaltungspanel (API), Ubuntu 24.04 LTS
Daemon	6	12 GB	80 GB	Gameserver-Daemon/Agent, Ubuntu 24.04 LTS
k6-runner	4	4 GB	—	Lastgenerator
Monitoring	2	4 GB	—	Prometheus + Grafana

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 #

Profil	VUs	Dauer	Testart
smoke	1	30 s	Latenz ohne Parallelität
baseline	10	4,5 min	Last
load	20 → 50 → 100	11 min	Last
stress	50 → 100 → 200 → 400 → 800	10 min	Stress
stress-1000	200 → 500 → 1000, 5 min gehalten	9 min	Stress
stress-1200	200 → 500 → 800 → 1200, 5 min gehalten	10 min	Stress
max-throughput	100, ohne Think-Time	2 min 40 s	Durchsatz

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.

Panel	Liste	Details	Status	Einträge in der Listen-Antwort
GameAP 3.x	`/api/servers`	`/api/servers/{id}`	dieselbe Anfrage wie Details¹	102
GameAP 4.x	`/api/servers`	`/api/servers/{id}`	`/api/servers/{id}/status`	102
PufferPanel	`/api/servers`	`/api/servers/{id}`	`/api/servers/{id}/status`	20 (erste Seite)
Pterodactyl	`/api/client`	`/api/client/servers/{id}`	`…/{id}/resources`	50 (erste Seite)
Pelican	`/api/client`	`/api/client/servers/{id}`	`…/{id}/resources`	50 (erste Seite)

¹ 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:

Panel	CPU	RAM
GameAP 4.x	0,4 %	449 MB
PufferPanel	0,6 %	462 MB
GameAP 3.x	3,2 %	1 049 MB
Pterodactyl	2,3 %	1 096 MB
Pelican	2,9 %	1 177 MB

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:

Profil	GameAP 4.x	PufferPanel	GameAP 3.x	Pterodactyl	Pelican
smoke (1 VU)	1,11	2,01	20,2	26,9	29,0
baseline (10 VUs)	0,82	1,54	9,24	12,7	16,0
load (bis 100 VUs)	0,59	1,37	8,78	20,7	54,5
stress (bis 800 VUs)	0,57	1,45	27,7	1 144	1 520
stress-1000	0,76	114	1 481	7 664	10 501
stress-1200	24,6	97,2	1 958	10 455	12 807

Perzentil, ms:

Profil	GameAP 4.x	PufferPanel	GameAP 3.x	Pterodactyl	Pelican
smoke (1 VU)	1,69	4,98	29,2	87,0	106
baseline (10 VUs)	1,45	2,08	19,9	79,4	97,0
load (bis 100 VUs)	1,20	1,85	13,2	154	473
stress (bis 800 VUs)	2,92	58,2	908	9 146	11 221
stress-1000	15,2	319	1 583	13 607	15 247
stress-1200	283	330	2 078	14 144	17 477

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.

Panel	RPS	Ø, ms	Median, ms	p95, ms
GameAP 4.x	1 126	77,6	68,9	179
PufferPanel	696	126	121	257
GameAP 3.x	394	222	241	302
Pterodactyl	93	941	766	1 825
Pelican	76	1 160	945	2 291

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:

Profil	GameAP 4.x	PufferPanel
load (bis 100 VUs)	0	0
stress (bis 800 VUs)	0	0,09
stress-1000	< 0,01	21,3
stress-1200	15,2	34,6

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:

Profil	GameAP 4.x	PufferPanel	GameAP 3.x	Pterodactyl	Pelican
stress (bis 800 VUs)	259	257	210	82	68
stress-1000	716	615	341	90	73
stress-1200	764	699	349	90	74

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, %:

Profil	GameAP 4.x	PufferPanel	GameAP 3.x	Pterodactyl	Pelican
smoke (1 VU)	0,4	0,6	3,2	2,3	2,9
baseline (10 VUs)	0,7	0,9	4,8	8,9	10,9
load (bis 100 VUs)	2,4	3,8	25,7	81,2	96,8
stress (bis 800 VUs)	20,4	65,3	100	100	100
stress-1000	40,0	95,6	100	100	100
stress-1200	87,7	96,1	100	100	100
max-throughput	96,1	95,3	100	100	100

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:

Prozess	GameAP 4.x	PufferPanel	GameAP 3.x	Pterodactyl	Pelican
Anwendung (Go / php-fpm)	31,5	73,1	318	243	260
Datenbank (PostgreSQL / MySQL)	2,9	9,5	31,4	109	94,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:

Profil	GameAP 4.x	PufferPanel	GameAP 3.x	Pterodactyl	Pelican
smoke (1 VU)	449	462	1 049	1 096	1 177
stress (bis 800 VUs)	480	539	1 288	1 463	1 606
stress-1200	701	744	1 354	1 469	1 610
max-throughput	641	672	1 342	1 445	1 556

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:

Endpunkt	GameAP 4.x	PufferPanel	GameAP 3.x	Pterodactyl	Pelican
`list_servers`	0,87	1,41	11,1	87,3	141
`server_details`	0,58	0,74	8,34	12,7	25,6
`server_status`	0,38	1,49	8,34	11,5	20,9

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.

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.
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).
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.
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.
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.
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.
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.
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.
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.
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.

Der GameAP-Blog ist zurück

Sun, 02 Aug 2026 12:00:00 +0300

Der GameAP-Blog ist zurück. Die alte Version war jahrelang unverändert geblieben und deutlich in die Jahre gekommen. Statt sie wiederzubeleben, haben wir den Blog daher von Grund auf neu aufgebaut — auf einer neuen Plattform und unter neuen Adressen.

Neue Adressen #

Der Blog lief früher unter einer einzigen Domain, gameap.blog, auf der die Sprachen über ein Pfadpräfix unterschieden wurden: gameap.blog/en/ und gameap.blog/ru/. Die englische und die russische Version haben jetzt ihre eigene Domain, die spanische und die deutsche sind über ein Pfadpräfix auf blog.gameap.com erreichbar:

blog.gameap.com — englische Version;
blog.gameap.ru — russische Version;
blog.gameap.com/es/ — spanische Version;
blog.gameap.com/de/ — deutsche Version.

Damit fügt sich der Blog in den Rest des Projekts ein: Die englischsprachigen Ressourcen finden sich unter gameap.com (Website, Dokumentation), die russischsprachigen unter gameap.ru.

Links auf die alte Domain gameap.blog funktionieren weiterhin — sie führen zu den neuen Adressen.

Jeder Artikel erscheint in allen vier Sprachen. Der Sprachumschalter im Seitenkopf führt zum selben Artikel in der anderen Sprache, nicht zur Startseite.

Was Sie erwartet #

Projektneuigkeiten — Ankündigungen neuer GameAP-Releases, Änderungen am Panel und am Daemon, Neues aus dem Plugin-Ökosystem.
Anleitungen — praxisnahe Artikel zum Einrichten von GameAP und zum Betrieb von Gameservern: von der Installation des Panels bis zum Feintuning.
Vergleiche, Benchmarks und ausführliche Analysen — alles, was nicht in die Dokumentation passt.

Nützliche Links #

Der erste große Artikel ist bereits in Arbeit — ein Lasttest der beliebtesten Control Panels für Gameserver.

Willkommen

Fri, 24 Apr 2020 00:00:00 +0300

Willkommen im GameAP-Blog. Hier werden Informationen zu GameAP-Releases, Anleitungen, Informationen zu Modulen usw. veröffentlicht.