Tenue en charge du sondage

[laem]

Quelques informations :

D'après cette question StackOverflow, la technologie websockets elle-même peut encaisser 1 million de connexions simultanées.

Cet autre article présente plutôt un tuto qui montre que c'est possible sur un PC d'il y a 6 ans, mais qu'il faut le configurer.

@Clemog je pense qu'on peut donc s'en sortir en réhaussant le scaling de nos serveurs, à la fois l'instance serveur et la base de données. À mon avis la BDD ne sera pas le facteur limitant, plutôt la mémoire du serveur.

Ça suppose par contre que le code de notre serveur ne provoque pas de fuite de mémoire par exemple. Très compliqué d'estimer ça, si ce n'est en simulant des milliers de connexions à un sondage.

Reste l'interface utilisateur, qui manipule N objets de ce type où N = nombre de réponses au sondage. Elle, on pourrait la tester facilement en simulant des réponses aléatoires. La logique des actions Redux, déclenchées à chaque changement dans la base de données (et non pas via des batch de changements temporels, disons par exemple toutes les 5 secondes), pourrait saturer l'interface Web.

C'est plus compliqué de tester le serveur en WebSockets, mais ça doit pouvoir se faire. Je ne sais pas si un seul client (par exemple mon ordinateur en localhost) peut simuler 100 000 connexions différentes au serveur, et non pas 1 seule connexion sur laquelle on ferait 100 000 actions.

Idéalement, on lancerait des navigateurs headless pour tester de vraies simulations, mais ça ça prendra beaucoup de ressources machine, impossible d'en faire tourner 1000 sur une seule machine, donc il faut trouver un autre moyen de tester.

[laem]

Lien avec #275