Blog de GameAP

¿Cómo publicar su plugin?

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

Los plugins de GameAP se publican en plugins.gameap.dev — desde ahí los usuarios los instalan directamente desde el panel. Esta guía recorre todo el camino: desde la creación de la ficha del plugin hasta la publicación automática de nuevas versiones desde CI.

Se presupone que su plugin ya está escrito y se compila en un .wasm. También necesitará una cuenta en plugins.gameap.dev: un registro normal con confirmación del correo electrónico, o inicio de sesión a través de GitHub, GitLab o Google.

Hay dos formas de subir una versión: manualmente a través del dashboard y a través de la API desde CI. Es más fácil empezar con el dashboard y, cuando la compilación se estabilice, pasar a CI.

Paso 1. Cuenta de desarrollador #

Publicar plugins requiere una cuenta con estado de desarrollador. Se concede gratis e inmediatamente — basta con aceptar las reglas de publicación.

En el catálogo de plugins pulse Publish your plugin — el botón de la esquina superior derecha.

El catálogo de plugins

Se abrirá la página con las reglas de publicación. En resumen, lo que usted acepta:

Plugins funcionales y de calidad — solo plugins operativos y probados, que hagan lo que promete su descripción.
Nada de código malicioso — sin puertas traseras, mineros ocultos ni lógica ofuscada; cualquier recopilación de datos de los usuarios debe describirse explícitamente.
Derechos y licencias — usted es propietario del código o está autorizado a distribuirlo, las licencias de terceros se respetan y la licencia del plugin está indicada.
Compatibilidad con GameAP — el plugin funciona con las versiones actuales del panel y cumple los requisitos del formato.
Actualizaciones y soporte — los errores críticos y las vulnerabilidades se corrigen en plazos razonables, y los reportes de los usuarios reciben respuesta.
Moderación — cada plugin y cada versión pasan una revisión, y un plugin que infrinja las reglas puede ser retirado en cualquier momento.
Sin spam ni duplicados — sin nombres engañosos ni relleno de palabras clave.

El texto completo está en la propia página, y vale la pena leerlo entero.

Pulse Agree al final de la página. El rol se concede al instante, sin revisión ni espera: en la barra lateral aparecerá la sección Developer con los apartados Dashboard, My Plugins, New Plugin y Support, y llegará un correo informándole de que ya es desarrollador.

Importante. Las reglas solo pueden aceptarse con un correo electrónico verificado: de lo contrario, el botón Agree permanece inactivo y la página muestra un recordatorio para confirmar la dirección. Las cuentas creadas a través de GitHub, GitLab o Google se consideran verificadas de inmediato.

El botón Publish your plugin es visible para todos, incluidos los visitantes que no han iniciado sesión. Sin sesión, la página de reglas muestra Log in to agree — al identificarse volverá a las reglas.

Paso 2. Creación del plugin #

Seleccione New Plugin en el menú de la izquierda — se abrirá el formulario de creación.

Creación de un nuevo plugin

Campo	Obligatorio	Qué indicar
Name	sí	Hasta 255 caracteres
Summary	sí	Una frase para la tarjeta del catálogo, hasta 500 caracteres
Description	sí	Descripción completa en Markdown — el campo tiene una barra de formato
Category	no	Una de las tres siguientes
Labels	no	Palabras clave que facilitan encontrar el plugin
License	no	Texto libre: `MIT`, `GPL-3.0`, `Proprietary`
Source URL	no	Enlace a las fuentes, si están abiertas
Repository URL	no	Enlace al repositorio
Homepage URL	no	El sitio web del plugin o del autor

Las categorías:

Server Management — la mayoría de los plugins. Todo lo que añade acciones sobre un servidor de juegos.
Files — extensiones del gestor de archivos: editores, visores de formatos concretos.
Integrations — plugins que amplían sustancialmente lo que el panel puede hacer, por ejemplo la gestión de bases de datos.

El icono no se puede subir en este paso — el formulario lo advierte explícitamente; el control de subida aparece justo después de la creación.

Importante. Source URL y Repository URL afectan a algo más que la ficha. Si ninguno de los dos está relleno, cada versión tendrá que incluir un archivo con el código fuente — los moderadores necesitan algo con lo que verificar la compilación. Rellene al menos uno de ellos si sus fuentes son públicas.

Paso 3. El ID del plugin #

Tras pulsar Create llegará a la página de edición del plugin. Su primer bloque es el Plugin ID — un campo de solo lectura con un botón para copiar.

Este ID hay que escribirlo en el código fuente del plugin — en el campo id de la estructura PluginInfo que devuelve el método GetInfo. Así es como el panel asocia un plugin instalado por el usuario con su entrada en el marketplace.

El ID se genera una sola vez al crear el plugin y no puede cambiarse. Internamente es un número de 64 bits (8 bytes aleatorios) escrito en base32 — 13 caracteres latinos y dígitos, por ejemplo fmqnme42gg7da. El mismo ID aparece en la URL de la página del plugin y en la dirección del endpoint de CI.

Cómo se ve en los plugins existentes:

plugin-mysql — la constante PLUGIN_ID (fmqnme42gg7da)
plugin-goldsrc-addons — PLUGIN_ID (ezvdsxmlu6fbk)
plugin-minecraft-modrinth — PLUGIN_ID (dshdabjp2l73a)

Importante. Escriba el ID y recompile el .wasm antes de subir la primera versión. Las versiones son inmutables: no se puede volver a subir un archivo con el mismo número, habría que incrementar la versión.

Paso 4. Icono y traducciones #

En esa misma página de edición se puede subir un icono: JPG, PNG, WebP o SVG, hasta 2 MB; se recomienda 128×128.

La página del plugin tiene un bloque Translations. El catálogo es bilingüe y cada visitante ve la ficha en su propio idioma: sin traducción, un usuario ruso recibirá la descripción en inglés y viceversa. El nombre, el resumen y la descripción se traducen por separado para cada idioma — cinco minutos de trabajo que cambian notablemente el aspecto de la ficha.

Paso 5. Subida de una versión #

En la página del plugin busque la tarjeta Versions y pulse Upload Version.

Subida de una nueva versión

Campo	Obligatorio	Qué indicar
Version	sí	Versión semántica: `1.0.0`, `1.2.0-beta.1`
Plugin File	sí	El `.wasm` compilado, hasta 100 MB
GPG Signature	no	Firma separada `.sig` o `.asc`, hasta 1 MB
Source Code Archive	depende	`.zip` o `.tar.gz`, hasta 50 MB
Changelog	no	Qué cambió respecto a la versión anterior, en Markdown
Stable Release	—	Un interruptor, activado por defecto
Min GameAP Version	no	La versión del panel a partir de la cual funciona el plugin

La firma GPG es opcional pero bienvenida: el servidor la almacena tal cual y nunca la verifica — existe para que los usuarios puedan comprobar por sí mismos la autenticidad del archivo.

El archivo de código fuente es obligatorio cuando el plugin no tiene rellenos ni Source URL ni Repository URL — el formulario cambia por sí solo la etiqueta del campo de «(Optional)» a «(Required)». El archivo se usa solo para la moderación y la verificación de la compilación; nunca se publica ni es accesible a través de ningún endpoint público.

Importante. Una versión subida a través del dashboard permanece como borrador. Hasta que no la envíe a revisión, nadie la ve.

Capturas de pantalla de la versión #

Justo después de la subida se abre un segundo paso — Add Screenshots. Las capturas pertenecen a una versión concreta: JPG, PNG o WebP, hasta 10, de 5 MB cada una. El paso se puede omitir y retomar más tarde desde la página de la versión.

Paso 6. Envío a revisión #

Los plugins pasan por moderación — conforme a las mismas reglas de publicación que aceptó en el paso 1. La cabecera de la página del plugin tiene un botón Submit for Review — solo es visible mientras el plugin está en estado Draft o Rejected.

Un plugin sin ninguna versión no puede enviarse — suba primero una versión. Enviar una versión a revisión desde la tabla de versiones también mueve el propio plugin de Draft a Pending Review, así que normalmente no hace falta pulsar el botón de la cabecera por separado.

Estado	Qué significa	Qué se puede hacer
Draft	Creado, no enviado a ninguna parte	Editar, enviar a revisión, eliminar
Pending Review	Esperando a un moderador	Esperar
Rejected	Un moderador lo devolvió	Corregirlo y enviarlo de nuevo
Released	Disponible para todos en el catálogo	Subir nuevas versiones
Approved	Un estado intermedio en el modelo de datos	—
Deprecated	Marcado como obsoleto	Aún instalable, pero señalizado
Retracted	Retirado de la publicación	No disponible para instalar

La aprobación mueve el plugin y la versión directamente a Released. Solo los objetos en ese estado son visibles públicamente: si un plugin está publicado pero su única versión sigue pendiente de revisión, no hay nada que instalar.

El motivo del rechazo llega por correo electrónico — la página del plugin solo muestra el estado, así que revise su bandeja de entrada.

Tokens de despliegue #

Para publicar versiones desde CI se necesita un token de despliegue. Está al final de la página del plugin, en la tarjeta Deploy Tokens.

La tarjeta de tokens de despliegue

Pulse Create Token y rellene el diálogo: un nombre (GitHub Actions, por ejemplo) y, opcionalmente, una fecha de caducidad.

Creación de un token de despliegue

Importante. El token se muestra exactamente una vez, justo después de su creación. En el servidor solo se guarda su hash y el valor no se puede recuperar — cópielo directamente en los secretos de su CI.

Lo que conviene saber sobre los tokens:

Un token está vinculado a un solo plugin y solo puede subir versiones de ese plugin. No abre ni otros plugins ni el resto de la API.
El formato es gapd_ más 43 caracteres, 48 en total. El prefijo lo detectan fácilmente los escáneres de secretos.
La tabla muestra el prefijo del token, la fecha de creación, el último uso y la caducidad — práctico para averiguar qué token sigue en uso.
La revocación es inmediata: un pipeline con un token revocado fallará en su próxima ejecución.
Un mismo plugin puede tener hasta 20 tokens.

Publicación desde CI #

El endpoint de CI acepta una nueva versión sin inicio de sesión interactivo — se autentica con un token de despliegue.

Subida con 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=Corregido un fallo al reiniciar el servidor" \
 -F "min_gameap_version=4.1.0" \
 -F "is_stable=true" \
 "https://plugins.gameap.dev/api/ci/plugins/$GAMEAP_PLUGIN_ID/versions"

La petición es un POST con multipart/form-data. Los campos del formulario:

Campo	Obligatorio	Descripción
`version`	sí	Versión semántica, p. ej. `1.2.3`
`file`	sí	El `.wasm` compilado, hasta 100 MB
`signature`	no	Firma GPG separada, hasta 1 MB
`source`	depende	Archivo de fuentes `.zip`/`.tar.gz` hasta 50 MB; obligatorio cuando el plugin no tiene ni Source URL ni Repository URL
`changelog`	no	Notas de la versión; cómodo pasarlas desde un archivo: `-F "changelog=<CHANGELOG.md"`
`min_gameap_version`	no	Versión mínima de GameAP
`min_plugin_api_version`	no	Versión mínima del Plugin API (el formulario del dashboard no tiene este campo)
`is_stable`	no	`true` o `1` marca la versión como estable
`submit`	no	Por defecto `true`; `false` mantiene la versión como borrador

No ponga una barra final en la URL. El router responde a .../versions/ con un 301, y curl no reenvía el cuerpo del POST en una redirección — la subida se convertiría silenciosamente en un GET.

Una respuesta exitosa es un 201 con un cuerpo como:

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

GitHub Actions #

Este workflow se dispara cuando se publica un release de GitHub, compila el plugin, lo firma y lo envía a plugins.gameap.dev. El cuerpo del release se convierte en el changelog, y la versión se marca como estable solo cuando el release no es un pre-release.

name: Publish plugin

on:
 release:
 types: [published]

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

 - name: Build plugin
 run: make wasm  # debe producir build/plugin.wasm

 - name: Sign plugin
 env:
 GPG_SIGNING_KEY: ${{ secrets.GPG_SIGNING_KEY }}
 run: |
 printf '%s' "$GPG_SIGNING_KEY" | gpg --batch --import
 gpg --batch --yes --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 "signature=@build/plugin.wasm.asc"
 -F "changelog=<${RUNNER_TEMP}/changelog.md")
 if [ "$PRERELEASE" != "true" ]; then
 ARGS+=(-F "is_stable=true")
 fi
 curl "${ARGS[@]}" \
 "https://plugins.gameap.dev/api/ci/plugins/${GAMEAP_PLUGIN_ID}/versions"

VERSION="${TAG#v}" elimina la v inicial para que el tag v1.2.3 se publique como versión 1.2.3.

La versión de producción de este workflow, con compilación del frontend, caché de Cargo y comprobación del estado HTTP, está en plugin-mysql.

Configuración del repositorio de GitHub #

El token y el ID del plugin no deben estar en el código — pertenecen a la configuración del repositorio. Abra Settings → Secrets and variables (en la sección Security and quality) → Actions.

La sección de configuración del repositorio

En la pestaña Secrets pulse New repository secret y añada:

Nombre	Valor
`GAMEAP_DEPLOY_TOKEN`	El token de despliegue que copió al crearlo (empieza por `gapd_`)
`GPG_SIGNING_KEY`	Una clave privada GPG en formato ASCII-armor, si firma sus compilaciones

Secretos del repositorio

En la pestaña Variables pulse New repository variable y añada:

Nombre	Valor
`GAMEAP_PLUGIN_ID`	El ID del plugin, p. ej. `fmqnme42gg7da`

Variables del repositorio

El ID del plugin es el mismo identificador base32 que escribió en PluginInfo. Cópielo con el botón junto al campo Plugin ID en la página de edición, o desde el bloque Details en la página del plugin.

El ID va en variables y no en secretos a propósito: no es un secreto, y tenerlo visible en los logs de CI facilita mucho el diagnóstico de fallos. El token, en cambio, siempre es un secreto.

Así se exporta una clave privada GPG para GPG_SIGNING_KEY:

gpg --armor --export-secret-keys SU_ID_DE_CLAVE

Publique la clave pública donde los usuarios puedan encontrarla — en el README del plugin, por ejemplo — para que la firma sea verificable.

Dashboard y CI: valores por defecto distintos #

Qué	Dashboard	CI
Stable release	El interruptor está activado por defecto	`is_stable` por defecto es false — pásalo explícitamente
Envío a revisión	Manual, pulsando un botón	`submit` por defecto es true — la versión va a revisión de inmediato
Capturas de pantalla	Se ofrecen justo después de la subida	No soportadas, añádalas a través del dashboard

Si lo único que quiere de CI es subir el archivo y terminar los metadatos a mano, pase submit=false y la versión permanecerá como borrador.

Errores #

Código	Causa
`400`	ID de plugin inválido, un multipart mal formado o no se pasó `file`
`401`	El token falta, es inválido o ha caducado; la cabecera no tiene la forma `Bearer gapd_...`
`403`	El token es válido pero fue emitido para otro plugin
`409`	Ya existe una versión con ese número
`422`	La versión no pasa la comprobación de semver; el archivo de fuentes falta, es demasiado grande o no es `.zip`/`.tar.gz`; se superan los límites de tamaño del archivo o de la firma

Los cuerpos de error tienen una forma común:

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

Tras un error 5xx, no reintente la subida a ciegas. Escribir la versión y enviarla a revisión no son una única transacción: la versión puede que ya exista, y un reintento devuelve 409. Abra el dashboard y compruebe qué pasó realmente.

Actualización y retirada de versiones #

Una nueva versión se sube exactamente igual que la primera — a través del dashboard o desde CI. Las versiones ya subidas son inmutables: volver a subir un archivo con el mismo número no es posible, el intento devuelve 409. Si la compilación salió mal, incremente la versión de parche.

Cada fila de la tabla de versiones tiene sus propias acciones:

Edit — cambiar el changelog y los metadatos.
Submit for Review — para borradores y versiones rechazadas.
Deprecate — para versiones publicadas. La versión sigue disponible pero se marca como obsoleta.
Retract — para versiones publicadas y obsoletas. La versión se retira de la publicación.

Solo se puede eliminar un plugin en estado Draft. Un plugin publicado no se puede eliminar — se puede retractar.

Lista de comprobación #

El correo está verificado, las reglas de publicación aceptadas y la cuenta tiene estado de desarrollador.
El plugin está creado, y el nombre y ambas descripciones están rellenos.
Source URL o Repository URL están rellenos — de lo contrario, cada versión necesita un archivo de fuentes.
El ID del plugin está escrito en PluginInfo.id y el .wasm se recompiló después.
El icono está subido y las traducciones de la ficha están en su sitio.
La versión está subida, con firma y capturas de pantalla adjuntas.
La versión está enviada a revisión, no dejada como borrador.
Para CI: un token de despliegue creado y guardado en los secretos, el ID del plugin en las variables.
El workflow no tiene barra final en la URL y pasa is_stable explícitamente.
Tras el release, se confirma que el plugin y la versión están en estado Released.

Pruebas de carga de paneles de control de servidores de juegos

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

Este artículo trata sobre las pruebas de carga de cinco populares paneles de control de servidores de juegos: GameAP 3, GameAP 4, PufferPanel, Pterodactyl y Pelican. Todos los paneles se prueban en el mismo hardware, en condiciones lo más parecidas posible; allí donde las condiciones no pudieron igualarse, se indica explícitamente en las limitaciones.

Aviso. Este artículo se publica en el blog de GameAP, y su autor es un desarrollador; GameAP 3 y GameAP 4 son dos de los cinco paneles sometidos a prueba. Esto supone un conflicto de intereses, y es legítimo esperar parcialidad. Para contrarrestarla, toda la prueba está construida para ser verificable: los scripts de k6, las configuraciones, los informes sin procesar de k6 y las métricas de monitorización de cada ejecución están publicados en un repositorio de GitHub. La metodología puede examinarse paso a paso, y la prueba puede repetirse en su propio hardware. Si cree que algún panel recibió una configuración incorrecta o que alguna conclusión está forzada, abra un issue: se volverá a comprobar y se publicará una corrección. Y una nota para quienes vinieron por la respuesta corta: sí, GameAP 4 obtuvo aquí las mejores cifras.

En resumen:

Con carga típica (10–100 usuarios concurrentes), los cinco paneles funcionan sin un solo error; lo que difiere es la latencia: milisegundos de un solo dígito para los paneles Go, alrededor de 9 ms para GameAP 3, decenas de milisegundos para Pterodactyl y Pelican.
El techo de rendimiento en este banco de pruebas:
- 1126 peticiones/s para GameAP 4
- 696 peticiones/s para PufferPanel
- 394 peticiones/s para GameAP 3
- 93 peticiones/s para Pterodactyl
- y 76 peticiones/s para Pelican
Bajo sobrecarga, los paneles fallan de forma distinta: los paneles Go empiezan a devolver errores; los paneles PHP no devuelven ningún error, pero los tiempos de respuesta crecen hasta segundos y decenas de segundos.
La mayor sorpresa: en saturación, MySQL en Pterodactyl y Pelican consume casi un núcleo de CPU completo, mientras que en GameAP 3, con el mismo MySQL y los mismos ajustes, la base de datos está tres veces menos ocupada con el doble de peticiones por segundo.

Objetivos #

Encontrar el punto de ruptura: el límite hasta el cual un panel sigue funcionando correctamente.
Comparar las alternativas en condiciones lo más parecidas posible.
Comparar GameAP 3 y GameAP 4: qué consiguió exactamente la reescritura de PHP a Go.

Además de la comparación general de los cinco paneles, tres duelos directos resultan de especial interés:

GameAP 3.x vs GameAP 4.x: una reescritura completa en Go con una arquitectura actualizada.
GameAP 4.x vs PufferPanel: una comparación de paneles escritos en Go.
Pterodactyl vs Pelican: el panel original frente a su fork.

Los paneles #

Panel	Versión	Stack	Base de datos	Daemon
GameAP 4.x	4.x	Go	PostgreSQL	gameap-daemon
PufferPanel	3.x	Go	PostgreSQL	integrado
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, fork de Pterodactyl	MySQL 8.0	Wings (Docker)

Los tres paneles PHP ejecutan además Redis (caché y sesiones). Las versiones se registran a nivel de rama mayor a fecha de abril de 2026, cuando se realizaron las ejecuciones.

Qué se pone a prueba #

latencia HTTP/API en distintos niveles de concurrencia: pruebas de carga (10–100 VUs);
comportamiento bajo sobrecarga (degradación, errores, consumo de recursos): pruebas de estrés (800–1200 VUs);
el techo de rendimiento sin pausas entre peticiones: pruebas de rendimiento.

Fuera del alcance de este artículo:

peticiones de escritura;
UX, funcionalidades, seguridad, ecosistema;
el trabajo con servidores de juegos reales y sus archivos;
estabilidad a largo plazo: no se ejecutaron pruebas soak ni spike.

Banco de pruebas #

Servidor (bare-metal, Selectel):

CPU: Intel Xeon E-2456 (Raptor Lake, 6C/12T, 3,3 GHz base / 5,1 GHz turbo, 18 MB L3);
RAM: 32 GB DDR5 ECC (2×16 GB, 4400 MT/s);
almacenamiento: 2× Samsung 990 PRO 1TB NVMe en mdadm RAID1;
hipervisor: Proxmox VE 9.1.5 sobre Debian 13, kernel 6.17.9-1-pve.

Configuración de las máquinas virtuales #

VM	vCPU	RAM	Disco	Rol
Panel	4	8 GB	40 GB	panel de control (API), Ubuntu 24.04 LTS
Daemon	6	12 GB	80 GB	daemon/agente de servidores de juegos, Ubuntu 24.04 LTS
k6-runner	4	4 GB	—	generador de carga
Monitorización	2	4 GB	—	Prometheus + Grafana

Ajustes del host #

gobernador de CPU: performance;
C-states limitados a C1;
Turbo Boost activado;
swap desactivado en todas las máquinas virtuales.

Metodología #

Los paneles se prueban de uno en uno: mientras un panel está en prueba, todas las demás VM están apagadas para evitar interferencias. Durante una ejecución, lo único que funciona es el panel (API), el daemon de servidores de juegos, el generador de carga k6 y la pila de monitorización.

Cada panel pasó por tres ejecuciones completas e independientes de toda la serie de perfiles (18–19 de abril de 2026). Todas las cifras de este artículo son medianas de las tres ejecuciones, salvo que se indique explícitamente lo contrario.

La secuencia para cada panel: arrancar sus dos VM (panel y daemon) → reiniciar los servicios → una ejecución de calentamiento del escenario smoke (1 VU, 30 s) → los perfiles de carga en orden. Antes de cada perfil se reinician los servicios del panel; después de cada perfil hay una pausa de 60 segundos. Los conjuntos de servicios reiniciados difieren entre paneles: para los paneles PHP son php-fpm, nginx y MySQL (más Redis en GameAP 3); para PufferPanel, la propia aplicación; para GameAP 4, solo nginx. Esta es una asimetría de la metodología; más detalles en las limitaciones.

Perfiles de carga #

Perfil	VUs	Duración	Tipo de prueba
smoke	1	30 s	latencia sin concurrencia
baseline	10	4,5 min	carga
load	20 → 50 → 100	11 min	carga
stress	50 → 100 → 200 → 400 → 800	10 min	estrés
stress-1000	200 → 500 → 1000, mantenido 5 min	9 min	estrés
stress-1200	200 → 500 → 800 → 1200, mantenido 5 min	10 min	estrés
max-throughput	100, sin think-time	2 min 40 s	rendimiento

Escenario #

Cada iteración realiza tres peticiones GET, las que los usuarios reales hacen con más frecuencia: la lista de servidores, los detalles de un servidor aleatorio de esa lista y su estado. Hay una pausa de 0,3–0,8 s entre peticiones y una pausa de 1–3 s al final de la iteración. El perfil max-throughput ejecuta las mismas tres peticiones sin pausas. No hay peticiones que modifiquen datos (POST, PUT, DELETE, etc.) en la prueba.

Panel	Lista	Detalles	Estado	Elementos en la respuesta de lista
GameAP 3.x	`/api/servers`	`/api/servers/{id}`	la misma petición que detalles¹	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 (primera página)
Pterodactyl	`/api/client`	`/api/client/servers/{id}`	`…/{id}/resources`	50 (primera página)
Pelican	`/api/client`	`/api/client/servers/{id}`	`…/{id}/resources`	50 (primera página)

¹ GameAP 3.x no tiene un endpoint de estado separado: se repite la petición de detalles.

Cada panel recibió 100 servidores de juegos ficticios idénticos (un script de relleno que imprime la hora; los servidores nunca se instalaron ni se iniciaron). Las respuestas de las API de lista difieren, sin embargo: GameAP devuelve todos los registros de una vez (la base de datos del banco de pruebas contenía 102), Pterodactyl y Pelican devuelven la primera página de 50, PufferPanel la primera página de 20. El tamaño medio de respuesta en el perfil load es de 13–16 KB por petición para cuatro paneles y de 1,6 KB para PufferPanel. Por tanto, una comparación directa de la latencia de list_servers entre paneles no es del todo justa: es una de las principales salvedades de esta prueba.

Autenticación y límites #

GameAP 3/4, Pterodactyl y Pelican utilizan una clave de API (Bearer). PufferPanel utiliza OAuth2 client credentials: el token se obtiene una vez en setup() y lo reutilizan todos los VUs. La propia petición OAuth (~58 ms) aparece en las estadísticas de cada perfil, porque setup() se ejecuta en cada invocación de k6. En el corto perfil smoke (31–34 peticiones) eleva la latencia media de PufferPanel de ~2 a ~3,7 ms, mientras la mediana no se mueve. En baseline es una petición de ~2 200, aproximadamente +0,03 ms (~2 %) en la media, con la mediana y los percentiles intactos; en los perfiles más largos el efecto es despreciable.

En Pterodactyl y Pelican, los límites de tasa de la API se elevaron a 10 000 peticiones por minuto; de lo contrario, la prueba habría topado con el limitador y no con el panel.

Ajustes de los paneles PHP (idénticos en GameAP 3, Pterodactyl y 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

Herramientas #

k6 v1.7.1; el tiempo de espera de petición por defecto es de 60 s;
Prometheus, node_exporter 1.8.2 (métricas de VM, paso de 15 s), process_exporter 0.8.7 (métricas de procesos, paso de 30 s).

El modelo de carga de bucle cerrado #

k6 utiliza un modelo de bucle cerrado: un usuario virtual no envía la siguiente petición hasta haber recibido la respuesta a la anterior. Cuando un panel se ralentiza, la intensidad de carga real desciende automáticamente. En un sistema abierto —usuarios reales, paneles que se actualizan automáticamente, integraciones— las peticiones seguirían llegando con independencia de las respuestas, y a un panel degradado le iría aún peor. Téngalo en cuenta al leer los resultados de estrés: las cifras de los paneles ralentizados son una estimación optimista. Más sobre el efecto: coordinated omission.

Observaciones del montaje del banco de pruebas #

Recursos de la VM del panel durante el perfil smoke: 1 VU, con la base de datos ya cargada con 100 servidores; pico en la ventana del perfil, mediana de tres ejecuciones:

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

La RAM corresponde a toda la máquina virtual (MemTotal − MemAvailable), incluidos el SO, la base de datos y los servicios auxiliares.

Observaciones recogidas durante el montaje del banco de pruebas:

Pterodactyl y Pelican no pueden funcionar detrás de NAT, ni el panel ni Wings: el navegador se conecta a Wings directamente por HTTP/HTTPS.
Pelican requiere reconstruir su caché de configuración tras los cambios de ajustes; de lo contrario, el panel falla.

Resultados #

Todas las cifras siguientes son medianas de tres ejecuciones; los informes sin procesar de cada ejecución están en el repositorio. Sobre la reproducibilidad: en los perfiles baseline, load y max-throughput, la latencia mediana difiere entre ejecuciones como máximo un 6,1 %, y el RPS como máximo un 2,7 %. El smoke es demasiado corto (28–34 peticiones por ejecución), así que la dispersión de su mediana alcanza el 22 %. En los perfiles de estrés el comportamiento es, como era de esperar, menos estable: la mediana de stress-1200 de GameAP 4 en las distintas ejecuciones, por ejemplo, fue 23,7 / 24,6 / 31,9 ms.

Latencia por nivel de carga #

Latencia mediana, ms:

Perfil	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 (hasta 100 VUs)	0,59	1,37	8,78	20,7	54,5
stress (hasta 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

Percentil 95, ms:

Perfil	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 (hasta 100 VUs)	1,20	1,85	13,2	154	473
stress (hasta 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

Qué muestra esto.

Hasta 100 VUs inclusive, los cinco paneles responden sin un solo error, y la única cuestión es la velocidad: los paneles Go se mantienen dentro de los 2 ms de mediana, GameAP 3 en torno a 9 ms, Pterodactyl 13–21 ms, Pelican 16–55 ms. La mediana de Pelican ya sube en el perfil load (54,5 ms, p95 — 473 ms): como mostrará la sección de recursos, a 100 VUs prácticamente se ha quedado sin CPU.

En los perfiles de estrés los grupos divergen radicalmente. GameAP 4 supera 800 y 1000 VUs sin degradación de la mediana (0,6–0,8 ms), PufferPanel se ralentiza hasta 114 ms a 1000 VUs y empieza a devolver errores, GameAP 3 aguanta 800 VUs con una mediana de 28 ms (p95 — 0,9 s) y pasa a 1,5–2 s por encima de 1000. Pterodactyl y Pelican ya responden en segundos a 800 VUs, y en 8–13 s (mediana) a 1000–1200.

Obsérvese la brecha entre la mediana y el p95 en los paneles PHP incluso a baja carga: la mediana de baseline de Pterodactyl es 12,7 ms mientras que su p95 es 79 ms. Su cola de respuestas lentas es larga incluso allí donde el panel en conjunto da la talla.

Techo de rendimiento #

El perfil max-throughput: 100 VUs ejecutan las mismas tres peticiones sin pausas — una rampa de subida de 30 s, 2 min de mantenimiento, una rampa de bajada de 10 s. El RPS se calcula como la media de toda la ventana, rampas incluidas.

Panel	RPS	Media, ms	Mediana, 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

Ningún panel devolvió un solo error, y sin embargo el rendimiento de los extremos difiere 15 veces (1126 frente a 76 peticiones/s). Conviene contrastarlo con la utilización de CPU: en este perfil cada panel funciona a su límite (95–100 % de la CPU de la VM — véase la tabla de recursos). Misma utilización, resultados separados por múltiplos: comparar paneles por «carga de CPU» carece de sentido; lo que importa es cuánto trabajo realiza un panel por núcleo.

Comportamiento bajo sobrecarga #

Peticiones fallidas (HTTP ≥ 400), % de todas las peticiones del perfil:

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

Los puntos de ruptura, según estos datos. PufferPanel es el primero en devolver errores: aislados (0,08–0,12 %) ya a 800 VUs, 21 % a 1000, 35 % a 1200 (hasta 40 % en la petición de lista). GameAP 4 supera 1000 VUs casi limpio (mediana: cero errores; 0,011 % en una de las tres ejecuciones) y devuelve 14,3–15,5 % de errores a 1200 VUs. Los paneles PHP no devuelven errores en absoluto, en ningún perfil.

Pero «0 % de errores» aquí no significa «el panel funciona». En stress-1200, el p95 de GameAP 3 es 2,1 s, el de Pterodactyl es 14,1 s, el de Pelican es 17,5 s. Formalmente cada petición termina recibiendo un 200 (k6 espera hasta 60 s); en la práctica, un panel que responde en 10–17 segundos es inutilizable. Son dos modos de degradación distintos, no «PHP aguanta y Go no»:

Los paneles Go — fail fast: una parte de las peticiones termina rápidamente en error, el resto se sirve con latencia aceptable (la mediana de GameAP 4 a 1200 VUs es 25 ms, la de PufferPanel es 97 ms). El cliente sabe de inmediato que el servidor está sufriendo.
Los paneles PHP — una cola: PHP-FPM encola las peticiones, no hay errores, pero el tiempo de respuesta crece sin límite. El cliente espera sin saber si llegará una respuesta.

Qué modo es el «correcto» es una cuestión de requisitos, no de benchmark. La consecuencia práctica es única: la sobrecarga de un panel PHP no aparecerá en la monitorización de errores, solo en la latencia.

RPS alcanzados en los perfiles de estrés:

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

Léase esta tabla con atención: debido a las pausas de think-time y a la rampa gradual de VUs, el perfil de estrés físicamente no puede entregar más de ~260 peticiones/s (el número medio temporal de VUs activos es ≈ 268, con ~3,1 s de pausas por iteración de tres peticiones). GameAP 4 y PufferPanel alcanzan el techo del perfil, no el suyo propio: 259 y 257. GameAP 3 logra 210. Pterodactyl y Pelican, en cambio, entregan aproximadamente su max-throughput en cada perfil de estrés (82–90 y 68–74 peticiones/s frente a techos de 93 y 76): el panel sirve lo que puede, el resto se acumula en la cola.

Recursos y cuellos de botella #

CPU pico de la VM del panel, %:

Perfil	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 (hasta 100 VUs)	2,4	3,8	25,7	81,2	96,8
stress (hasta 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

La fila clave es load: la carga «de trabajo» de 100 usuarios concurrentes, que todos los paneles superan con cero errores, cuesta a GameAP 4 y PufferPanel un 2–4 % de CPU, a GameAP 3 un 26 %, a Pterodactyl un 81 % y a Pelican un 97 %. Pterodactyl y Pelican ya funcionan al borde de la saturación en este perfil: no les queda margen para picos.

A dónde va la CPU bajo sobrecarga: procesos en el perfil de estrés (800 VUs), pico en la ventana, media de las ejecuciones 2–3:

Proceso	GameAP 4.x	PufferPanel	GameAP 3.x	Pterodactyl	Pelican
Aplicación (Go / php-fpm)	31,5	73,1	318	243	260
Base de datos (PostgreSQL / MySQL)	2,9	9,5	31,4	109	94,3

100 % = un núcleo, 4 vCPU en total. Nginx se mantuvo ≤ 3,2 % en cada ejecución; Redis, donde process_exporter lo vio, ≤ 5,1 % (la cobertura de monitorización del proceso de Redis resultó incompleta: en algunas ejecuciones process_exporter no lo rastreó; no cambia el panorama, pero se deja fuera de la tabla).

La fila más interesante es la de la base de datos. En Pterodactyl y Pelican, MySQL consume 94–109 % de CPU — casi un núcleo completo — mientras sirve 68–82 peticiones por segundo. En GameAP 3, el mismo MySQL 8.0 con los mismos ajustes está ocupado un 31 %, a 210 peticiones por segundo. Por petición, Pterodactyl y Pelican queman aproximadamente nueve veces más tiempo de CPU de base de datos que GameAP 3. Al parecer, el cuello de botella de estos paneles no es PHP como tal, sino su carga de trabajo de base de datos. La causa no se perfiló y sigue siendo una cuestión abierta; un pase de EXPLAIN sobre las consultas de los endpoints de lista se sugiere por sí mismo.

RAM pico de la VM, MB:

Perfil	GameAP 4.x	PufferPanel	GameAP 3.x	Pterodactyl	Pelican
smoke (1 VU)	449	462	1 049	1 096	1 177
stress (hasta 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

RSS de procesos en stress-800 (media de las ejecuciones 2–3): la aplicación — 65 MB para GameAP 4 y 107 MB para PufferPanel frente a 2,7–4,2 GB de RSS total entre cincuenta workers de php-fpm; la base de datos — 107 MB de PostgreSQL en GameAP 4 frente a ~613–641 MB de MySQL. Dos salvedades: el RSS de los workers de php-fpm cuenta la memoria compartida muchas veces (el consumo real de la VM está en la tabla anterior), y el RSS de PostgreSQL de PufferPanel varió notablemente entre ejecuciones (721 MB en la primera, ~440 MB en la segunda y la tercera).

Y una anomalía que honestamente sigue sin explicación: PufferPanel es el único panel que escribe activamente en disco bajo carga — picos de 140–150 IOPS de escritura frente a 4 de GameAP 4 y 21–24 del resto. La causa (¿logs? ¿auditoría? ¿particularidades del uso de PostgreSQL?) no se investigó.

Lo que muestran los endpoints individuales #

Latencia mediana por endpoint en el perfil load, ms:

Endpoint	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

La lista de servidores es la petición más pesada en todos los paneles, pero en Pterodactyl y Pelican la brecha es dramática: la lista es 7–8 veces más lenta que la petición de detalles (87 y 141 ms frente a 13 y 26 ms). Es la petición de lista la que se degrada primero bajo carga.

Un recordatorio de la salvedad de la metodología: el tamaño de la respuesta de lista difiere entre paneles (102 registros para GameAP, 50 para Pterodactyl/Pelican, 20 para PufferPanel), así que comparar la fila de list_servers entre paneles no es justo. Lo que sí puede leerse de esta tabla es la proporción entre endpoints dentro de un mismo panel, y el hecho de que GameAP 4 devuelve su lista completa de 102 registros (~13 KB) más rápido que cualquier panel PHP devuelve su primera página.

Las tres comparaciones directas #

GameAP 3 → GameAP 4. Para esto fue la reescritura: la mediana de baseline es 9,24 frente a 0,82 ms (11×), la mediana de load es 8,78 frente a 0,59 ms (15×), el techo de rendimiento es 394 frente a 1126 peticiones/s (2,9×), la memoria de toda la VM es 1,0–1,4 GB frente a 0,45–0,70 GB, la CPU en el perfil load es 26 % frente a 2,4 %.

GameAP 4 vs PufferPanel. Ambos son Go + PostgreSQL, y ambos son un orden de magnitud más rápidos que el grupo PHP. Entre los dos: GameAP 4 es 1,9–2,3× más rápido por mediana en baseline/load y 1,6× por el techo de rendimiento (1126 frente a 696), se rompe más tarde bajo sobrecarga (15 % de errores a 1200 VUs frente al 21 % de PufferPanel ya a 1000 y los primeros errores aislados a 800) y apenas toca el disco. Téngase en cuenta, sin embargo, que en este escenario PufferPanel devuelve un orden de magnitud menos datos por petición de lista (20 registros, ~1,6 KB frente a 102 registros, ~13 KB): la brecha se midió sobre un trabajo más ligero para PufferPanel.

Pterodactyl vs Pelican. El fork resultó más lento que el original en todos los perfiles: en load la mediana es 54,5 frente a 20,7 ms, p95 — 473 frente a 154 ms, el techo — 76 frente a 93 peticiones/s, y la saturación de CPU llega antes (97 % ya en load frente a 81 %). Por procesos, el php-fpm de Pelican está más ocupado (260 frente a 243 %) y su MySQL menos (94 frente a 109 %). Las causas de las diferencias no se investigaron; en el momento de la prueba Pelican era un fork joven (1.0.x), y su perfil de rendimiento aún puede cambiar.

Limitaciones #

Una lista de lo que limita las conclusiones de esta prueba.

Bases de datos distintas entre los grupos. Los paneles Go funcionaron sobre PostgreSQL, los paneles PHP sobre MySQL 8.0 (en ambos casos, las configuraciones recomendadas por los desarrolladores de los paneles). Cualquier comparación «Go vs PHP» aquí significa en realidad «Go+PostgreSQL vs PHP+MySQL»: esta prueba no separa la contribución de la base de datos de la del lenguaje y la arquitectura. Dentro de cada grupo las bases de datos son idénticas.
Tamaños de respuesta de list_servers distintos. Cada base de datos contiene 100 servidores, pero GameAP devuelve la lista completa (102 registros), Pterodactyl/Pelican la primera página de 50, PufferPanel la primera página de 20; los tamaños de respuesta van de 1,6 a 16 KB. La prueba no normalizó la paginación a un tamaño de página común. Las comparaciones directas de latencia de lista entre paneles están, por tanto, sesgadas; a favor de quién depende del par (el sesgo aligera el trabajo de PufferPanel y lo hace más pesado para GameAP).
GameAP 3 no tiene endpoint de estado: su server_status es una repetición de la petición de detalles, así que un tercio del escenario en GameAP 3 no es equivalente al de los demás paneles.
Solo lectura, solo API. Sin escrituras, sin WebSocket, sin UI; los servidores ficticios nunca se instalaron ni se iniciaron, y los daemons de las VM vecinas estuvieron prácticamente ociosos. Es una prueba de la capa HTTP/API de los paneles, no de los paneles en su conjunto.
El modelo de bucle cerrado de k6 (véase la metodología): los paneles degradados recibieron automáticamente menos carga, así que sus cifras de estrés son una estimación optimista. El tiempo de espera de petición de k6 es de 60 s.
Calentamiento. Una ejecución de calentamiento smoke (30 s) antes de la serie de perfiles, y un reinicio de servicios antes de cada perfil. En los paneles que no están limitados por CPU (GameAP 3/4, PufferPanel), la latencia media en baseline es mayor que en el perfil load, más pesado (0,85 → 0,66 ms; 1,49 → 1,27; 10,9 → 9,7): parte de la ventana de baseline aparentemente sigue siendo calentamiento. No cambia las conclusiones, pero las cifras absolutas de baseline están ligeramente infladas.
Asimetría de reinicio. Antes de cada perfil, a los paneles PHP se les reinició php-fpm, nginx y MySQL (buffer pool y cachés vaciados; en GameAP 3 también Redis), a PufferPanel se le reinició la aplicación (PostgreSQL siguió en marcha), y a GameAP 4 solo se le reinició nginx (la aplicación y PostgreSQL no). Los paneles PHP empezaron cada perfil «más fríos». Las fases de rampa de los perfiles compensan esto parcialmente, pero la asimetría no se eliminó por completo.
Versiones registradas a nivel mayor (GameAP 4.x / 3.x, Pterodactyl 1.11.x, Pelican 1.0.x, PufferPanel 3.x, abril de 2026). GameAP 4 es funcionalmente más joven y más simple que el resto: hacer menos trabajo por petición puede ser parte de su ventaja; eso no se cuantificó.
Límites modificados. En Pterodactyl y Pelican, los límites de tasa se elevaron a 10 000 peticiones/min; una instalación estándar habría cortado la carga antes.
Monitorización. CPU y RAM son métricas de toda la VM con paso de 15 s (los picos cortos pueden suavizarse); las métricas de procesos tienen paso de 30 s, y la cobertura del proceso de Redis entre ejecuciones es incompleta; las estadísticas de smoke de PufferPanel incluyen la petición OAuth de setup(). Una configuración de hardware, una disposición de VM, 100 servidores en la base de datos: con otro hardware y otros volúmenes de datos, las cifras absolutas diferirán.

Conclusiones #

Volvamos a las tres preguntas de los objetivos.

¿Cuánto difieren los paneles con carga normal? En el perfil load (hasta 100 usuarios concurrentes), los cinco paneles funcionan con cero errores, y la latencia difiere en un orden de magnitud o más: 0,6–1,4 ms de mediana para los paneles Go, ~9 ms para GameAP 3, 21–55 ms para Pterodactyl/Pelican. Dicho sin rodeos: para una persona en un navegador, incluso 55 ms es rápido. Si usted opera un panel, una docena de servidores y ninguna automatización, cualquiera de los contendientes parecerá instantáneo. La diferencia se vuelve práctica con integraciones y automatización, con operaciones masivas, en hardware barato, y en el precio de esa velocidad: los mismos 100 VUs cuestan a Pelican un 97 % de CPU y a GameAP 4, un 2,4 %.

¿Dónde está el punto de ruptura y cómo se rompe un panel? Por techo de rendimiento: 1126 (GameAP 4) → 696 (PufferPanel) → 394 (GameAP 3) → 93 (Pterodactyl) → 76 (Pelican) peticiones/s. Bajo sobrecarga hay dos modos: los paneles Go fallan rápido con errores (PufferPanel desde 800–1000 VUs, GameAP 4 desde 1200), los paneles PHP no devuelven errores pero responden en segundos o decenas de segundos. La conclusión práctica para la monitorización: la sobrecarga de un panel PHP solo es visible en la latencia; no habrá alertas de errores.

¿Cuál es el cuello de botella? Para GameAP 4, la propia CPU de la aplicación (la base de datos apenas está cargada). Para PufferPanel, la aplicación más escrituras de disco notables cuya causa no se investigó. Para GameAP 3, php-fpm (318 % de CPU con MySQL al 31 %). Para Pterodactyl y Pelican el panorama es distinto: junto a php-fpm, MySQL consume casi un núcleo completo; por petición, eso es aproximadamente nueve veces más tiempo de CPU de base de datos del que GameAP 3 gasta en el mismo MySQL. Este es el resultado más interesante de la prueba, y merece una investigación aparte con perfilado de consultas.

Esta prueba mide un solo corte: la velocidad de lectura de la capa HTTP/API. No dice nada sobre funcionalidades, usabilidad, seguridad o ecosistema, y la elección de un panel también depende de eso. GameAP 4 ganó este benchmark, pero también es el contendiente más joven; Pterodactyl perdió en las cifras, y sin embargo sigue siendo el panel más extendido y con el mayor ecosistema. Qué hacer con estos hechos es decisión suya.

Qué sigue #

Fase 2 — gestión de servidores de juegos: arranque/parada masivo de N servidores, estado estacionario con servidores en ejecución, consolas WebSocket en paralelo, creación de servidores vía la API. Para ello se está preparando un fake-game-server: un binario que imita a un servidor de juegos real.
Escalado por volumen de datos: ejecuciones con 1 / 100 / 1000 servidores en la base de datos, para medir cómo depende la latencia de los endpoints de lista del tamaño de la base de datos.
Cuestiones abiertas de esta fase: las escrituras de disco de PufferPanel, el perfilado de las consultas MySQL de Pterodactyl/Pelican, la diferencia entre Pelican y Pterodactyl.

Los scripts, las configuraciones y los datos sin procesar de todas las ejecuciones están en el repositorio game-panels-benchmark. Si encuentra un fallo en la metodología o en la interpretación, abra un issue: se volverá a comprobar y se publicará una corrección.

El blog de GameAP está de vuelta

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

El blog de GameAP está de vuelta. La versión anterior llevaba años sin actualizarse y había envejecido mal, así que, en lugar de resucitarla, reconstruimos el blog desde cero: con una nueva plataforma y nuevas direcciones.

Nuevas direcciones #

Antes el blog vivía en un solo dominio, gameap.blog, donde los idiomas se distinguían por un prefijo en la ruta: gameap.blog/en/ y gameap.blog/ru/. Ahora cada idioma tiene su propio dominio:

blog.gameap.com — versión en inglés;
blog.gameap.ru — versión en ruso.

Así el blog queda en línea con el resto del proyecto: los recursos en inglés están en gameap.com (sitio web, documentación), y los recursos en ruso están en gameap.ru.

Los enlaces al antiguo dominio gameap.blog siguen funcionando: le llevan a las nuevas direcciones.

Cada artículo se publica en ambos idiomas. El selector de idioma en la cabecera del sitio le lleva al mismo artículo en el otro dominio, no a la página de inicio.

Qué puede esperar #

Noticias del proyecto — anuncios de lanzamientos de GameAP, cambios en el panel y en el daemon, novedades del ecosistema de plugins.
Guías — artículos prácticos sobre el despliegue de GameAP y la administración de servidores de juegos: desde la instalación del panel hasta el ajuste fino.
Comparativas, mediciones de rendimiento y análisis en profundidad: lo que no cabe en la documentación.

Enlaces útiles #

El primer gran artículo ya está en marcha: pruebas de carga de los paneles de control de servidores de juegos más populares.

Bienvenido

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

Bienvenido al blog de GameAP. Aquí se publicará información sobre las versiones de GameAP, guías, información sobre módulos, etc.