Capacidade medida em produção
20.000 pessoas. Nenhuma ligação perdida.
Todos os números desta página vêm de um teste de carga contra o pollslive.com real, não de uma cópia de testes nem de uma projeção numa folha de cálculo. Em baixo tem o método, os resultados completos e o limite que não ultrapassámos.
Última medição: 20 de julho de 2026
O que medimos
Quatro números, cada um de um teste identificado contra a produção. Todos com a sua ressalva.
2,500
pessoas a responder à mesma pergunta ao mesmo tempo
As 2.500 respostas aceites, nenhuma perdida, a um ritmo sustentado de 100 respostas por segundo.
2026-07-20
20 ms
tempo mediano para aceitar uma resposta
p95 77 ms, p99 104 ms, resposta mais lenta 140 ms, na mesma sala de 2.500 pessoas.
2026-07-20
20,000
participantes em direto em simultâneo
Os 20.000 ligaram-se e receberam a difusão de estado. Zero falhas, p99 de ligação 34 ms.
2026-07-11
8,000
pessoas a ver os resultados a atualizar em direto
Zero falhas. Um teste posterior manteve 4.000 espectadores com a tempestade de respostas ainda a decorrer.
2026-07-11
O momento que realmente importa
Ninguém se preocupa se as pessoas conseguem entrar. Preocupa-se com o segundo em que revela a pergunta e a sala inteira responde ao mesmo tempo. Isso é uma rajada de escritas na base de dados, e é aí que estas ferramentas caem. Por isso forçámos de propósito: sala real, entradas reais, respostas reais através do gateway real.
| Tamanho da sala | Ritmo de resposta | Respostas aceites | Falhadas | Tempo de aceitação p50 / p95 / p99 |
|---|---|---|---|---|
| 300 | 25/seg | 300 | 0 | 17 / 31 / 46 ms |
| 1.500 | 50/seg | 1.500 | 0 | 16 / 35 / 66 ms |
| 2.500 | 100/seg | 2.500 | 0 | 20 / 77 / 104 ms |
Leia a última coluna de cima para baixo. A sala cresce oito vezes e o ritmo quatro vezes, e a mediana quase não se move. É esse o ponto: o tempo de resposta não se degrada à medida que a sala cresce.
Porque se mantém plano
A contagem em direto era antes recalculada a partir de todas as respostas do slide, pelo que cada nova resposta custava um pouco mais do que a anterior - aceitável com 200 pessoas, mau com 2.000. Agora é um contador incremental, o que torna o custo de uma resposta independente de quantas vieram antes.
Pôr toda a gente na sala
Antes de responder é preciso entrar. Cada participante mantém um WebSocket aberto durante toda a sessão, por isso a questão é quantas ligações uma máquina aguenta e quanto espera a pessoa mais lenta para entrar.
| Participantes | Ligados | Falhados | Ligação mais lenta (p99) |
|---|---|---|---|
| 1.000 | 1.000 | 0 | 9 ms |
| 3.000 | 3.000 | 0 | 8 ms |
| 5.000 | 5.000 | 0 | 7 ms |
O teste de julho levou esta dimensão a 20.000 participantes em simultâneo, sem falhas e com um p99 de ligação de 34 ms, no mesmo hardware.
Onde para
Publicar um limite é mais útil do que escondê-lo, por isso aqui está o nosso. As escritas são a superfície crítica: cerca de 100 respostas por segundo correm limpas em toda a plataforma, e à volta de 180 por segundo a máquina desiste. O recurso limitante é o CPU de um host partilhado de 4 núcleos, não a base de dados, cujo pool de ligações nunca esteve perto de esgotar em nenhum dos testes.
É daqui que vêm os limites dos planos
Uma sala de N pessoas a responder em cerca de dez segundos produz N/10 escritas por segundo. Fazendo as contas ao contrário a partir do limite, obtêm-se os tetos de participantes em direto que aplicamos mesmo: 50 no Free, 1.000 no Pro, 1.500 no Team, 2.500 com um Event Pass e 5.000 no Enterprise. Não são arbitrários nem um muro de pagamento disfarçado de engenharia.
Não afirmamos ter escala ilimitada. Se a sua sala for maior do que os números acima, diga-nos antes do evento e responderemos com honestidade.
Como testámos
Contra produção real
Não uma cópia. Os geradores atacaram o mesmo proxy, os mesmos contentores, a mesma base de dados e o mesmo gateway em tempo real que servem o pollslive.com, fora de horas de ponta e com um travão de emergência ao primeiro sinal de um 5xx ou health check falhado.
Com os limitadores contornados
Cada pedido sintético levava um IP de cliente forjado e único para que os limitadores por IP não mascarassem a capacidade. Queríamos medir o servidor, não a nossa própria porta de entrada.
E com limpeza no fim
Cada teste usou um espaço de trabalho, uma sondagem e uma sessão descartáveis, apagados no fim e verificados sem linhas residuais. A produção manteve-se estável, tal como o site alheio que partilha a máquina.
De forma conservadora
Os geradores de carga correram na mesma máquina que estavam a testar e consumiram cerca de um núcleo. Os limites reais com clientes externos são ligeiramente superiores aos publicados.
As ferramentas que produziram estes números
As quatro estão no repositório. Nada aqui foi medido com um script que não possa ler.
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
Os relatórios completos
Ambos os relatórios, incluindo os testes que falharam e os estrangulamentos ainda por resolver, estão versionados junto ao código.
- Teste de capacidade e stress
docs/LOAD_TEST_CAPACITY_2026-07.md2026-07-11 - Teste de regressão do caminho em direto
docs/LOAD_TEST_REGRESSION_2026-07-20.md2026-07-20
Traga a sua maior sala
Grátis para começar, sem cartão e sem conta para criar uma. Se aguenta 2.500 pessoas a responder ao mesmo tempo, aguenta a sua reunião geral.