Evénements envoyés par le serveur ou interrogation

Question

Y a-t-il une grande différence (en termes de performances, de disponibilité de l'implémentation du navigateur, de charge du serveur, etc. HTML5 SSEs et l'interrogation directe par Ajax ? Du côté du serveur, il semble qu'un EventSource ne fait que frapper la page spécifiée toutes les ~3 secondes environ (même si je comprends que le timing est flexible).

Il est vrai que c'est plus simple à mettre en place du côté du client que d'installer une minuterie et de la faire fonctionner. $.get de temps en temps, mais y a-t-il autre chose ? Est-ce qu'il envoie moins d'en-têtes, ou est-ce qu'il fait une autre magie qui m'échappe ?

Answer 1

L'interrogation Ajax ajoute beaucoup de frais généraux HTTP puisqu'elle établit et détruit constamment des connexions HTTP. Comme HTML5 Rocks le met "En revanche, les événements envoyés par le serveur ont été conçus dès le départ pour être efficaces."

Les événements envoyés par le serveur ouvrent une seule connexion HTTP à longue durée de vie. Le serveur envoie alors des données de manière unidirectionnelle lorsqu'il en a. Le client n'a pas besoin de les demander ou de faire autre chose qu'attendre les messages.

L'un des inconvénients des événements envoyés par le serveur est que, puisqu'ils créent une connexion persistante avec le serveur, vous pouvez potentiellement avoir de nombreuses connexions ouvertes à votre serveur. Certains serveurs mieux gérer un grand nombre de connexions simultanées que d'autres. Cela dit, vous auriez des problèmes similaires avec l'interrogation, plus les frais généraux liés au rétablissement constant de ces connexions.

Les événements envoyés par le serveur sont assez bien supporté par la plupart des navigateurs l'exception notable étant bien sûr IE. Mais il y a un couple de polyfills (et un plugin jQuery ) qui corrigera cela.

Si vous faites quelque chose qui ne nécessite qu'une communication unidirectionnelle, j'opterais définitivement pour les événements envoyés par le serveur. Comme vous l'avez mentionné, les événements envoyés par le serveur ont tendance à être plus simples et plus propres à mettre en œuvre du côté client. Il suffit de mettre en place des écouteurs pour les messages et les événements et le navigateur s'occupe des choses de bas niveau comme la reconnexion en cas de déconnexion, etc. Du côté serveur, il est également assez facile à mettre en œuvre puisqu'il s'agit d'un simple texte. Si vous envoyez des objets codés en JSON, vous pouvez facilement les transformer en objets JavaScript sur le client grâce à la fonction JSON.parse() .

Si vous utilisez PHP sur le serveur, vous pouvez utiliser json_encode() pour transformer les chaînes de caractères, les nombres, les tableaux et les objets en JSON correctement codé. D'autres langages dorsaux peuvent également fournir des fonctions similaires.

Answer 2

J'ajouterais seulement une perspective plus élevée à ce qui a été dit, à savoir que l'ESS est un modèle de publication-abonnement par opposition à l'interrogation constante dans le cas d'AJAX.

En général, les deux méthodes (polling et publish-subscribe) tentent de résoudre le problème du maintien d'un état à jour sur le client.

1) Modèle de scrutin

Le principe est simple. Le client (navigateur) reçoit d'abord un état initial (page) et pour qu'il soit mis à jour, il doit périodiquement demander l'état (page ou sa partie) et traiter le résultat dans l'état actuel (rafraîchir la page entière ou la rendre intelligemment dans sa partie en cas d'AJAX).

Naturellement, un inconvénient est que si rien ne se passe avec l'état du serveur, les ressources (CPU, réseau, ...) sont utilisées inutilement. Un autre inconvénient est que même si l'état change, les clients ne l'obtiennent qu'à la période d'interrogation suivante, et non pas immédiatement. Il est souvent nécessaire d'évaluer un bon compromis entre les deux.

Un autre exemple de polling est un spinwait dans le threading.

2) Modèle de publication et d'abonnement

Il fonctionne comme suit :

• (le client demande d'abord et montre un certain état initial)
• le client s'abonne au serveur (il envoie une requête, éventuellement accompagnée d'un contexte tel que la source de l'événement).
• le serveur marque la référence au client à certains de ses référentiels de référence client
• dans le cas d'une mise à jour de l'état, le serveur envoie une notification au client sur la base de la référence au client qu'il détient ; c'est-à-dire qu'il ne s'agit pas d'une réponse à une demande mais d'un message initié par le serveur.
• les bons clients se désabonnent lorsqu'ils ne sont plus intéressés par les notifications

Il s'agit de l'ESS ou, dans le cadre d'un threading, d'un événement à attendre, comme autre exemple. L'inconvénient naturel, comme indiqué, est que le serveur doit connaître tous ses clients abonnés, ce qui, selon l'implémentation, peut poser problème.