Rendimiento y escalado

El 27 de octubre de 2026, un solo servidor Go gestionó 10.000 conexiones WebSocket autenticadas de WebSpace y entregó los 100.000 eventos previstos. La prueba de carga mixta con SQLite3 también completó 1.000 escrituras y 10.000 lecturas mientras mantenía abiertas 10.000 conexiones.

Puede descargar los resultados de validación y las mediciones de cada ejecución (JSON). Estas pruebas utilizaron la ruta de tiempo real propia de WebSpace, por separado del chat de Workspace.

Entorno y configuración de la prueba

Se utilizó una compilación de desarrollo dedicada que omitía la comprobación del nivel de licencia. La autenticación, los permisos y las comprobaciones de Origin siguieron la ruta normal de WebSpace. Las bases de datos se guardaron en ext4 sobre disco, no en un sistema de archivos en memoria (tmpfs). Los generadores no limitaron la velocidad de lectura ni las escrituras pendientes.

Los límites HTTP se configuraron con requestsPerSecond y burst bajo webspace.rateLimits.read, webspace.rateLimits.mutation y webspace.rateLimits.handshake, y se aplicaron al reiniciar. Estos valores de prueba difieren de los predeterminados. Los límites de conexiones en tiempo real se gestionan en Servicios y capacidad.

Conexiones y entrega de 5.000 a 10.000

Cada conexión recibió diez eventos y se realizaron tres ejecuciones por escala. No hubo eventos perdidos, duplicados ni entregados a otra sala en ninguna ejecución.

Los tiempos son las medianas de tres ejecuciones. El tiempo de conexión incluye el inicio de los generadores, el aumento gradual de conexiones, la autenticación y la suscripción. El p95 de entrega es el percentil 95 del tiempo entre enviar y recibir cada evento; se muestra la mediana de los tres p95. La prueba de septiembre medía la recepción de los diez eventos de cada conexión, por lo que sus latencias no son directamente comparables.

1.000 escrituras y 10.000 lecturas en SQLite3

Con 10.000 conexiones autenticadas abiertas, se iniciaron 1.000 cambios de estado de un recurso compartido junto con 10.000 lecturas HTTP. Las escrituras se ejecutaron en serie mediante la cola de cada base de datos.

La duración abarca desde el inicio de las lecturas y escrituras, una vez establecidas las conexiones, hasta su finalización. La concurrencia configurada de 10.000 describe cómo los clientes emiten solicitudes. SQLite no ejecutó 10.000 consultas a la vez; el grupo de lectura permitía hasta ocho conexiones.

Todas las lecturas devolvieron HTTP 200, sin respuestas HTTP 429 ni errores de escritura. En la prueba con concurrencia de 10.000, el p95 de escritura fue de 858 ms y el de lectura de unos 2,88 s. Las cuatro bases de datos de prueba tenían 1.000 acciones únicas, valor del recurso de 100.000→99.000, versión 1.000 y 1.000 recompensas. SQLite integrity_check devolvió ok en las cuatro.

Conexiones activas, salas y reconexión

Con 10.000 conexiones se enviaron diez eventos en cada una de doce rondas, con cinco segundos de espera entre rondas. Se completaron las 1.200.000 entregas en unos 67,27 segundos, sin pérdidas ni duplicados. Tras cerrar bruscamente y reconectar 100 conexiones, llegaron también los 10.000 eventos posteriores.

Otra prueba distribuyó las conexiones entre 100 salas de 100 conexiones cada una. Llegaron los 100.000 eventos iniciales, sin entregas a otras salas. También se verificó la entrega tras 20 segundos de inactividad y después de reconectar 100 conexiones. En los 15 casos, el máximo RSS observado del servidor fue de unos 1,50 GiB. Al terminar no quedó ninguna conexión abierta.

Efectos de la latencia y la ruta de almacenamiento

En la prueba de conexiones activas, la revalidación periódica de tokens de todo el espacio de suscripciones coincidió con valores p95 de entrega de unos 1,91–2,31 segundos por ronda. Por ello, los 312 ms de las pruebas cortas no garantizan una latencia sostenida.

Una prueba anterior utilizó el sistema de archivos compartido de Windows en WSL (9p). Solo se completaron 414 de las 1.000 escrituras concurrentes; las restantes superaron el límite de cinco segundos de espera y transacción. Los resultados correctos anteriores se obtuvieron con un disco virtual ext4 de WSL en el mismo SSD NVMe. Los resultados pueden variar según el método de acceso al almacenamiento.

Con el límite de lectura predeterminado de 500 solicitudes/segundo por IP y ráfaga de 1.200, 37 lecturas devolvieron HTTP 429. Las pruebas finales elevaron los límites HTTP en lugar de reducir la velocidad de los generadores.

Elegir la configuración según la carga

La cola ordena las escrituras concurrentes, pero la capacidad de procesamiento sigue siendo limitada. Las conexiones de esta prueba son sockets autenticados de una sola cuenta. No se validaron los flujos completos de 10.000 usuarios distintos ni una carga prolongada. Realice mediciones adicionales con TLS, proxies, WAN y la mezcla de operaciones de producción.

En Operaciones puede revisar solicitudes, errores, tiempos de respuesta y estado de la DB. Para un flujo completo de usuario, pruebe el ejemplo de Crear un juego de Gomoku en tiempo real.