Cómo automatizar pruebas de carga en el GameServer de tu servidor de MU Online

Lanzar un servidor de MU Online sin saber cuántos jugadores simultáneos soporta realmente es una apuesta a ciegas: el primer día de difusión, cuando más gente intenta entrar al mismo tiempo, es justamente el peor momento para descubrir que el ConnectServer se traba en 200 conexiones o que la base de datos satura el pool antes de lo esperado. Este tutorial muestra cómo armar un pipeline de prueba de carga automatizado, simulando conexiones y acciones simultáneas en el ConnectServer y GameServer, midiendo los indicadores correctos e identificando el límite real de tu entorno antes de que los jugadores lo hagan por vos.

Por qué probar la carga antes del lanzamiento

Una difusión exitosa (grupos, YouTube, Discords aliados) suele generar un pico de accesos concentrado en las primeras horas después del lanzamiento — muy por encima del promedio que el servidor va a sostener después. Si el entorno se rompe en ese pico, la primera impresión de los jugadores es pésima y buena parte no vuelve a intentar. Probar la carga con anticipación permite corregir cuellos de botella (configuración de base de datos, hardware subdimensionado, límite de conexiones del SO) mientras todavía no hay jugadores reales en riesgo.

Diferenciando los tipos de prueba

No toda prueba de carga necesita simular el juego entero. Dividir por capa facilita aislar dónde está el cuello de botella:

Preparando el entorno de staging

Nunca corras la prueba de carga contra la base de datos/servidor de producción — el riesgo de corromper datos reales o tumbar el servidor durante la difusión es demasiado alto. Cloná la configuración (mismas versiones de emulador, misma configuración de base de datos, hardware lo más parecido posible) en un entorno aislado, con datos de prueba sintéticos:

CREATE DATABASE mu_staging;
-- Restaurá un dump limpio/sintético, nunca datos reales de jugadores

Simulando conexiones en el ConnectServer

El ConnectServer es el primer cuello de botella en un pico de acceso — resuelve a qué GameServer debe ir el cliente y mantiene una cola de conexiones. Un script simple en Python, usando sockets crudos, puede simular cientos de handshakes:

import socket
import threading
import time

def simular_conexao(host, porta, resultados, i):
    inicio = time.time()
    try:
        s = socket.create_connection((host, porta), timeout=5)
        s.close()
        resultados.append(time.time() - inicio)
    except Exception as e:
        resultados.append(None)

resultados = []
threads = []
for i in range(500):
    t = threading.Thread(target=simular_conexao, args=("staging.miservidor.com", 44405, resultados, i))
    threads.append(t)
    t.start()
    time.sleep(0.01)  # espacia levemente para simular llegada gradual

for t in threads:
    t.join()

sucesso = [r for r in resultados if r is not None]
print(f"Conexiones exitosas: {len(sucesso)}/{len(resultados)}")
print(f"Latencia promedio: {sum(sucesso)/len(sucesso):.3f}s")

Esta prueba básica ya revela si el ConnectServer acepta las conexiones rápidamente o empieza a encolar/rechazar por encima de determinado volumen.

Simulando el flujo de login completo

Para medir el cuello de botella real de autenticación (que involucra la consulta a la base de cuentas), hay que emular el protocolo de paquetes de tu emulador — la estructura varía entre IGCN, MuEMU y X-Team, pero el principio es el mismo: armar el paquete de login binario y leer la respuesta:

import struct

def montar_pacote_login(conta, senha):
    # Estructura simplificada — ajustá a los offsets reales de tu emulador
    corpo = conta.encode('ascii').ljust(10, b'\x00') + senha.encode('ascii').ljust(10, b'\x00')
    tamanho = len(corpo) + 4
    return struct.pack('BBB', 0xC1, tamanho, 0xF1) + corpo

Correr este paquete de forma concurrente contra el GameServer de staging, midiendo el tiempo hasta la respuesta de éxito/falla, muestra la capacidad real de autenticación simultánea — generalmente el cuello de botella aparece primero acá, no en la conexión TCP en sí.

Probando concurrencia en la base de datos

Independientemente de la prueba de red, la base de datos suele ser el límite real de escala. Usá sysbench para simular carga de lectura/escritura equivalente al patrón de acceso del servidor (muchas lecturas de personaje, pocas escrituras de posición cada pocos segundos):

sysbench oltp_read_write \
  --db-driver=mysql --mysql-db=mu_staging \
  --mysql-user=teste --mysql-password=senha \
  --tables=10 --table-size=100000 \
  --threads=200 --time=120 \
  run

Comparé los resultados de latencia (p95, p99) de sysbench con el número de jugadores simultáneos esperado — si el p99 ya se degrada con 200 threads simulados y tu meta es 500 CCU, la base de datos (no el GameServer) es el cuello de botella a resolver primero.

Monitoreando recursos durante la prueba

Mientras la prueba corre, recolectá métricas del sistema en paralelo para correlacionar carga con consumo de recursos:

# En una ventana separada, durante toda la prueba:
top -b -n 100 -d 5 | grep -E "GameServer|ConnectServer|mysqld" >> /tmp/monitor_carga.log
vmstat 5 100 >> /tmp/monitor_carga.log

Definiendo los escenarios de prueba (rampa gradual)

En vez de disparar todos los "jugadores simulados" de una vez (lo que no refleja el patrón real de llegada), estructurá la prueba en rampa — aumentando la carga gradualmente y observando en qué punto cada métrica empieza a degradarse:

Automatizando la ejecución del pipeline completo

Un script orquestador simple encadena las etapas y guarda los resultados con timestamp, para comparar ejecuciones a lo largo del tiempo (por ejemplo, antes y después de una optimización de configuración):

#!/bin/bash
DATA=$(date +%F_%H%M)
mkdir -p /tests/$DATA

python3 teste_conexao.py > /tests/$DATA/conexao.log &
sysbench oltp_read_write --threads=200 --time=300 run > /tests/$DATA/banco.log &
top -b -d 5 -n 60 > /tests/$DATA/recursos.log &

wait
echo "Prueba de carga $DATA completada. Resultados en /tests/$DATA/"

Interpretando los resultados y actuando sobre ellos

El objetivo final no es solo generar números, es decidir acciones concretas. Un resultado típico de análisis:

• Si la latencia de login se degrada antes de que la CPU del GameServer sature, el cuello de botella es el pool de conexiones de la base de datos — aumentá max_connections en MySQL/MSSQL y ajustá el pool del emulador.
• Si la CPU del GameServer satura primero, el hardware está subdimensionado para la meta de CCU — considerá un upgrade de vCPU u optimizar la lógica de eventos que corren en loop.
• Si la red se degrada con pocos cientos de conexiones, el enlace contratado puede ser insuficiente para el volumen esperado — revisá el plan con el proveedor.

Errores comunes y soluciones

Lista de verificación de prueba de carga

• Entorno de staging aislado, con specs equivalentes a producción.
• Script de simulación de conexión en el ConnectServer funcionando.
• Script de simulación de login/autenticación probado.
• Prueba de concurrencia de base de datos (sysbench) ejecutada y analizada.
• Monitoreo de CPU, memoria, conexiones y disco recolectado durante la prueba.
• Rampa gradual de carga ejecutada hasta identificar el punto de ruptura.
• Acciones correctivas definidas en base a los cuellos de botella encontrados.
• Reprueba realizada después de los ajustes para confirmar la mejora.

Con el límite real de tu entorno mapeado antes del lanzamiento, cambiás las sorpresas de producción por decisiones de dimensionamiento tomadas con datos. Si la base de tu servidor todavía está en configuración inicial, empezá por el tutorial de creación de servidor de MU Online antes de invertir tiempo en pruebas de carga avanzadas.

Preguntas frecuentes