Capacidad medida en producción
20.000 personas. Ninguna conexión perdida.
Cada número de esta página procede de una prueba de carga contra el pollslive.com real, no de una copia de pruebas ni de una proyección en una hoja de cálculo. Abajo tienes el método, los resultados completos y el límite que no hemos cruzado.
Última medición: 20 de julio de 2026
Lo que medimos
Cuatro cifras, cada una de una prueba concreta contra producción. Todas con su matiz.
2,500
personas respondiendo la misma pregunta a la vez
Las 2.500 respuestas aceptadas, ninguna perdida, a un ritmo sostenido de 100 respuestas por segundo.
2026-07-20
20 ms
tiempo mediano para aceptar una respuesta
p95 77 ms, p99 104 ms, la respuesta más lenta 140 ms, en esa misma sala de 2.500 personas.
2026-07-20
20,000
participantes simultáneos en directo
Los 20.000 se conectaron y recibieron la difusión de estado. Cero fallos, p99 de conexión 34 ms.
2026-07-11
8,000
personas viendo los resultados actualizarse en directo
Cero fallos. Una prueba posterior mantuvo 4.000 espectadores mientras la tormenta de respuestas seguía activa.
2026-07-11
El momento que de verdad importa
Nadie se preocupa por si la gente puede entrar. Se preocupa por el segundo en que revelas la pregunta y toda la sala responde a la vez. Eso es una ráfaga de escrituras en base de datos, y ahí es donde estas herramientas se caen. Así que lo forzamos a propósito: sala real, entradas reales, respuestas reales a través de la pasarela real.
| Tamaño de sala | Ritmo de respuesta | Respuestas aceptadas | Fallidas | Tiempo de aceptación p50 / p95 / p99 |
|---|---|---|---|---|
| 300 | 25/seg | 300 | 0 | 17 / 31 / 46 ms |
| 1500 | 50/seg | 1500 | 0 | 16 / 35 / 66 ms |
| 2500 | 100/seg | 2500 | 0 | 20 / 77 / 104 ms |
Lee la última columna de arriba abajo. La sala se multiplica por ocho y el ritmo de respuesta por cuatro, y la mediana apenas se mueve. Ese es el punto: el tiempo de respuesta no se degrada cuando la sala crece.
Por qué se mantiene plano
El recuento en directo se recalculaba antes a partir de todas las respuestas de la diapositiva, así que cada respuesta nueva costaba algo más que la anterior: aceptable con 200 personas, feo con 2.000. Ahora es un contador incremental, lo que hace que el coste de una respuesta sea independiente de cuántas hubo antes.
Meter a todo el mundo en la sala
Antes de responder hay que entrar. Cada participante mantiene un WebSocket abierto durante toda la sesión, así que aquí se trata de cuántas conexiones aguanta una máquina y cuánto espera la persona más lenta en entrar.
| Participantes | Conectados | Fallidos | Conexión más lenta (p99) |
|---|---|---|---|
| 1000 | 1000 | 0 | 9 ms |
| 3000 | 3000 | 0 | 8 ms |
| 5000 | 5000 | 0 | 7 ms |
La prueba de julio llevó esta dimensión a 20.000 participantes simultáneos, sin fallos y con un p99 de conexión de 34 ms, en el mismo hardware.
Dónde se detiene
Publicar un límite es más útil que esconderlo, así que aquí está el nuestro. Las escrituras son la superficie crítica: unas 100 respuestas por segundo funcionan limpias en toda la plataforma, y alrededor de 180 por segundo es donde la máquina se rinde. El recurso que manda es la CPU de un host compartido de 4 núcleos, no la base de datos, cuyo pool de conexiones nunca estuvo cerca de agotarse en ninguna de las dos pruebas.
De aquí salen los límites de los planes
Una sala de N personas respondiendo en unos diez segundos produce N/10 escrituras por segundo. Si haces la cuenta hacia atrás desde el límite, salen los topes de participantes en directo que realmente aplicamos: 50 en Free, 1000 en Pro, 1500 en Team, 2500 con un Event Pass y 5000 en Enterprise. No son arbitrarios ni un muro de pago disfrazado de ingeniería.
No afirmamos tener escala ilimitada. Si tu sala es mayor que las cifras de arriba, dínoslo antes del evento y te responderemos con honestidad.
Cómo lo probamos
Contra producción real
No una copia. Los generadores atacaron el mismo proxy, los mismos contenedores, la misma base de datos y la misma pasarela en tiempo real que sirven pollslive.com, fuera de horas punta y con un botón de parada al primer indicio de un 5xx o de un health check fallido.
Con los limitadores desactivados
Cada petición sintética llevaba una IP de cliente falsificada y única para que los limitadores por IP no enmascarasen la capacidad. Queríamos medir el servidor, no nuestra propia puerta de entrada.
Y limpiando después
Cada prueba usó un espacio de trabajo, una encuesta y una sesión desechables, borrados al final y verificados sin filas residuales. Producción se mantuvo estable, igual que el sitio ajeno que comparte máquina.
De forma conservadora
Los generadores de carga se ejecutaron en la misma máquina que estaban probando y consumieron cerca de un núcleo. Los límites reales con clientes externos son algo más altos que lo publicado.
Las herramientas que produjeron estas cifras
Las cuatro están en el repositorio. Nada de esto se midió con un script que no puedas leer.
scripts/load-test/answer-storm.mjslive answers through the gatewayscripts/load-test/realtime-load.mjsconcurrent WebSocket participantsscripts/load-test/sse-flood.mjsconcurrent live-results viewersscripts/load-test/vote-storm.mjsasync vote write throughput
Los informes completos
Ambos informes, incluidas las pruebas que fallaron y los cuellos de botella que aún no hemos resuelto, están versionados junto al código.
- Prueba de capacidad y estrés
docs/LOAD_TEST_CAPACITY_2026-07.md2026-07-11 - Prueba de regresión del camino en directo
docs/LOAD_TEST_REGRESSION_2026-07-20.md2026-07-20
Trae tu sala más grande
Gratis para empezar, sin tarjeta y sin cuenta para crear una. Si aguanta 2.500 personas respondiendo a la vez, aguantará tu reunión general.