Événements envoyés par le serveur et diffusion en continu avec Rails

Question

Je suis en train d'expérimenter avec Rails 4 ActionController::Live et Server Sent Events. J'utilise MRI 2.0.0 et Puma.

D'après ce que je peux voir, chaque client connecté maintient une connexion active avec le serveur. Je me demandais s'il était possible de tirer parti des SSE sans maintenir tous les flux de réponse en cours d'exécution.

Puma gère plusieurs connexions en utilisant des threads, et j'imagine qu'il y a une limite au nombre de connexions simultanées.
Que se passerait-il si je voulais prendre en charge un scénario réel avec des milliers de clients s'inscrivant à mon application Rails pour des événements SSE?

Y a-t-il un exemple?

De plus, j'ai l'habitude de faire fonctionner les serveurs d'applications Rails derrière un proxy inverse nginx. Cela nécessiterait-il une configuration particulière?

Answer 1

La façon dont les SSE sont construits est que le client ouvre une connexion au serveur, qui est ensuite laissée ouverte jusqu'à ce que le serveur ait des données à envoyer. Cela fait partie de la spécification SSE, et n'est pas spécifique à ActionController::Live. C'est essentiellement la même chose que le long polling, mais avec la connexion qui n'est pas fermée après le premier peu de données retournées, et avec le mécanisme intégré au navigateur.

En tant que tel, la seule façon de le mettre en œuvre est d'avoir plusieurs connexions client ouvertes vers le serveur Web qui restent indéfiniment. En ce qui concerne les ressources nécessaires pour les gérer, je ne suis pas sûr, car je n'ai pas encore essayé de mesurer cela, mais il faudra suffisamment de serveurs pour que Puma maintienne ouvertes des milliers de connexions si vous avez autant d'utilisateurs avec une page ouverte.

La limite par défaut pour puma est de 16 connexions simultanées. Plusieurs blogs sur la configuration des SSE pour Rails mentionnent une augmentation de cette valeur, mais aucun de ceux que j'ai trouvés ne suggère quelle devrait être cette valeur plus élevée. Ils mentionnent que le nombre de connexions DB devra être le même, car chaque thread Rails en garde une en cours d'exécution. Cela ressemble à une façon coûteuse de gérer les choses.

"Faire un test de performance" est vraiment la seule réponse.

Je ne peux pas commenter sur la mise en place d'un proxy inverse car je ne l'ai pas essayé, mais comme les SSE se font via HTTP standard, je ne pense pas qu'il aura besoin d'une configuration spéciale.