Capacité mesurée en production
20 000 personnes. Aucune connexion perdue.
Chaque chiffre de cette page provient d'un test de charge contre le vrai pollslive.com, pas d'une copie de préproduction ni d'une projection sur tableur. Voici la méthode, les résultats complets et le plafond que nous n'avons pas franchi.
Dernière mesure : 20 juillet 2026
Ce que nous avons mesuré
Quatre chiffres, chacun issu d'un test identifié contre la production. Chacun avec sa nuance.
2,500
personnes répondant à la même question en même temps
Les 2 500 réponses acceptées, aucune perdue, à un rythme soutenu de 100 réponses par seconde.
2026-07-20
20 ms
temps médian pour accepter une réponse
p95 77 ms, p99 104 ms, réponse la plus lente 140 ms, dans cette même salle de 2 500 personnes.
2026-07-20
20,000
participants simultanés en direct
Les 20 000 se sont connectés et ont reçu la diffusion d'état. Zéro échec, p99 de connexion 34 ms.
2026-07-11
8,000
personnes suivant les résultats en direct
Zéro échec. Un test ultérieur a tenu 4 000 spectateurs pendant que la tempête de réponses tournait encore.
2026-07-11
Le moment qui compte vraiment
Personne ne s'inquiète de savoir si les gens arrivent à rejoindre. On s'inquiète de la seconde où vous révélez la question et où toute la salle répond d'un coup. C'est une rafale d'écritures en base, et c'est là que ces outils lâchent. Nous l'avons donc provoquée délibérément : vraie salle, vraies connexions, vraies réponses via la vraie passerelle.
| Taille de la salle | Rythme de réponse | Réponses acceptées | Échecs | Temps d'acceptation p50 / p95 / p99 |
|---|---|---|---|---|
| 300 | 25/s | 300 | 0 | 17 / 31 / 46 ms |
| 1 500 | 50/s | 1 500 | 0 | 16 / 35 / 66 ms |
| 2 500 | 100/s | 2 500 | 0 | 20 / 77 / 104 ms |
Lisez la dernière colonne de haut en bas. La salle est multipliée par huit et le rythme par quatre, et la médiane bouge à peine. C'est tout l'enjeu : le temps de réponse ne se dégrade pas quand la salle grandit.
Pourquoi cela reste plat
Le décompte en direct était auparavant recalculé à partir de toutes les réponses de la diapositive : chaque nouvelle réponse coûtait donc un peu plus que la précédente - acceptable à 200 personnes, catastrophique à 2 000. C'est désormais un compteur incrémental, ce qui rend le coût d'une réponse indépendant du nombre de réponses déjà reçues.
Faire entrer tout le monde
Avant de répondre, il faut rejoindre. Chaque participant garde un WebSocket ouvert pendant toute la session : la question est donc de savoir combien de connexions une seule machine supporte, et combien de temps attend la personne la plus lente.
| Participants | Connectés | Échecs | Connexion la plus lente (p99) |
|---|---|---|---|
| 1 000 | 1 000 | 0 | 9 ms |
| 3 000 | 3 000 | 0 | 8 ms |
| 5 000 | 5 000 | 0 | 7 ms |
Le test de juillet a poussé cette dimension à 20 000 participants simultanés, sans aucun échec et avec un p99 de connexion de 34 ms, sur le même matériel.
Où cela s'arrête
Publier une limite est plus utile que la cacher, alors voici la nôtre. Les écritures sont la surface critique : environ 100 réponses par seconde passent proprement sur toute la plateforme, et autour de 180 par seconde la machine abandonne. La ressource limitante est le CPU d'un hôte partagé à 4 cœurs, pas la base de données, dont le pool de connexions n'a jamais approché la saturation lors des deux tests.
C'est de là que viennent les limites des offres
Une salle de N personnes répondant en une dizaine de secondes produit N/10 écritures par seconde. En remontant depuis le plafond, on obtient les plafonds de participants réellement appliqués : 50 en Free, 1 000 en Pro, 1 500 en Team, 2 500 avec un Event Pass et 5 000 en Enterprise. Ils ne sont ni arbitraires ni un péage déguisé en ingénierie.
Nous ne prétendons pas offrir une capacité illimitée. Si votre salle dépasse ces chiffres, dites-le-nous avant l'événement et nous répondrons honnêtement.
Comment nous avons testé
Contre la vraie production
Pas une copie. Les générateurs ont attaqué le même proxy, les mêmes conteneurs, la même base et la même passerelle temps réel qui servent pollslive.com, en heures creuses, avec un coupe-circuit au premier 5xx ou health check en échec.
Avec les limiteurs contournés
Chaque requête synthétique portait une IP client forgée et unique afin que les limiteurs par IP ne masquent pas la capacité. Nous voulions mesurer le serveur, pas notre propre porte d'entrée.
Et nettoyé ensuite
Chaque test utilisait un espace de travail, un sondage et une session jetables, supprimés à la fin et vérifiés sans ligne résiduelle. La production est restée verte, tout comme le site tiers qui partage la machine.
De façon conservatrice
Les générateurs de charge tournaient sur la machine même qu'ils testaient et en consommaient près d'un cœur. Les plafonds réels avec des clients externes sont donc légèrement supérieurs aux chiffres publiés.
Les outils qui ont produit ces chiffres
Les quatre sont dans le dépôt. Rien ici n'a été mesuré avec un script que vous ne pouvez pas lire.
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
Les rapports complets
Les deux rapports, y compris les essais qui ont échoué et les goulots que nous n'avons pas encore corrigés, sont versionnés avec le code.
- Test de capacité et de charge
docs/LOAD_TEST_CAPACITY_2026-07.md2026-07-11 - Test de régression du chemin en direct
docs/LOAD_TEST_REGRESSION_2026-07-20.md2026-07-20
Amenez votre plus grande salle
Gratuit pour démarrer, sans carte, sans compte pour en créer un. Si l'outil tient 2 500 personnes qui répondent en même temps, il tiendra votre réunion plénière.