Notification du client, dois-je utiliser un push ou un sondage AJAX?

Question

Je travaille sur un simple service de notification qui sera utilisé pour envoyer des messages aux utilisateurs qui naviguent sur un site Web. Les notifications ne doivent pas nécessairement être envoyées en temps réel, mais l'expérience de l'utilisateur serait meilleure si elles arrivaient plus souvent que toutes les 5 minutes. Les données envoyées vers et depuis le client ne sont pas très volumineuses et il s’agit d’une requête directe dans la base de données pour récupérer les données.

En lisant d'autres conversations sur le sujet, il semblerait qu'un push AJAX peut entraîner des charges de serveur plus importantes. Étant donné que je peux tolérer des délais plus longs sur le serveur, cela vaut la peine de recevoir des notifications push du serveur ou simplement de procéder à une interrogation.

Il n’est pas beaucoup plus difficile de mettre en œuvre le scénario «push» et j’ai donc pensé voir ce que l’opinion était ici.

Merci de votre aide.

EDIT: J'ai examiné un simple AJAX Push et mis en œuvre une simple démo basée sur ceci article de Mike Purvis. La charge du client est relativement faible, autour de 5k pour la version initiale, et devrait le rester pendant un certain temps.

Merci à tous pour vos réponses. J’ai décidé d’utiliser la solution de sondage, mais de tout intégrer dans une bibliothèque d’utilitaires afin que, s’ils souhaitent la modifier plus tard, c’est plus facile.

Answer 1

Etant donné que l'utilisation d'un push nécessite de maintenir une connexion HTTP ouverte entre votre serveur et chaque client, j'irais aussi pour un sondage. Non seulement cela va consommer beaucoup de ressources du serveur, mais cela va également prendre beaucoup plus délicat à mettre en œuvre, comme le dit Matt b. ??

Mon expérience des interrogations est que, si l'intervalle d'interrogation est assez fréquent sur un site suffisamment occupé, les journaux de votre serveur Web peuvent être inondés de requêtes d'interrogation très rapidement.

Modifier (2017) : Je dirais que vos choix se situent maintenant entre les Websockets et les longues interrogations (mentionnées dans une autre réponse). Une longue interrogation peut sembler être le bon choix compte tenu de la façon dont la question indique que les notifications ne doivent pas nécessairement être reçues en temps réel. Une période d'interrogation peu fréquente serait assez facile à mettre en œuvre et ne devrait pas être très éprouvante pour votre serveur. . Les Websockets sont sympas et constituent un excellent choix pour de nombreuses applications de nos jours. Toutefois, cela pourrait sembler excessif dans ce cas.

Answer 2

Je suis surpris que personne ici n'ait mentionné les sondages longs. Une interrogation longue signifie conserver une connexion ouverte pendant une période plus longue (par exemple, 30 à 60 secondes). Une fois fermée, rouvrir à nouveau et simplement laisser le socket / connexion écouter les réponses. Cela entraîne moins de connexions (mais plus longues) et signifie que les réponses sont presque immédiates (certaines peuvent devoir attendre une nouvelle connexion en interrogation). J'aimerais ajouter qu'en combinaison avec des technologies telles que NodeJS, il en résulte une solution très efficace et peu gourmande en ressources, compatible à 100% avec tous les navigateurs et versions principaux, et ne nécessitant aucune technologie supplémentaire comme Comet ou Flash.

Je réalise que c’est une vieille question, mais je pense qu’il pourrait toujours être utile de fournir cette information:)

Answer 3

Utilisez certainement push son beaucoup plus froid. Si vous souhaitez simplement des notifications simples, j'utiliserais un logiciel comme StreamHub Push Server pour faire le gros travail pour vous. Développer votre propre fonctionnalité Ajax Push est une route extrêmement difficile et rocailleuse - vous devez la faire fonctionner dans tous les navigateurs, puis gérer les pare-feu et les mandataires tuant les connexions persistantes, etc. ... Pourquoi réinventer la roue. En outre, son encombrement similaire est inférieur à 10 000. Il devrait donc vous convenir si cela est une priorité pour vous.

Answer 4

Les deux ont des exigences différentes et abordent différents scénarios.

Si vous avez besoin de mises à jour en temps réel , comme dans un chat en ligne, la diffusion est essentielle.

Toutefois, si la période d'actualisation est longue , comme dans votre cas (5 minutes), pool est la solution appropriée. Dans ce cas, le push nécessitera beaucoup de ressources du client et du serveur.

Conseil! : essayez de rendre la page qui vérifie le pool rapide et propre, de sorte qu'elle ne consomme pas beaucoup de ressources sur le serveur à chaque demande. Ce que je fais habituellement, c’est de garder en mémoire (comme dans une variable de session) un indicateur indiquant si le pool est vide ou non ... alors, je ne regarde dans le pool que s’il n’est pas vide. Lorsque le pool est vide, ce qui est généralement le cas, la demande de page est extrêmement rapide.

Answer 5

J'implémenterais un sondage simplement parce que cela paraissait plus simple à écrire, et le garder simple est très précieux.

Answer 6

Vous ne savez pas si vous avez jeté un coup d'œil à certaines des implémentations de COMET (est-ce ce que vous entendez par AJAX push)?

Si l'utilisateur navigue sur le site, ne demandera-t-il pas au serveur des informations sur lesquelles cette notification peut se greffer?

Answer 7

Il est impossible de dire si les sondages seront plus coûteux que de pousser sans connaître le nombre de clients que vous aurez. Je vous recommanderais de voter car:

• On dirait que vous souhaitez mettre à jour les données environ une fois par minute. Si les notifications ne parviennent pas à un rythme beaucoup plus rapide, cela signifie que vous gardez une connexion HTTP ouverte mais que vous ne voyez que très peu d’activité dessus.
• La scrutation étant basée sur les conventions HTTP existantes, tout serveur qui communique avec les navigateurs Web est déjà prêt à répondre aux requêtes Ajax ordinaires. Une comète & # 8211; ou la solution basée sur une prise Flash & # 8211; a des exigences différentes; vous aurez besoin de quelque chose comme cometd du côté serveur et une bibliothèque côté client qui fait gruger le côté serveur.

Donc, si vous aviez besoin de quelque chose de lourd pour gérer un torrent de données et un téléchargement complet de clients, je vous recommanderais Comet. Mais cela ne semble pas être le cas.

Answer 8

Il existe maintenant un service http://pusherapp.com qui tente de résoudre ce problème une fois pour toutes, en un clin d'oeil. Ça vaut peut-être la peine de vérifier. (disclaimer: je ne suis aucunement associé à eux).

Answer 9

Je n'ai pas essayé moi-même, mais certains disent que COMET fonctionne et est plus facile que vous ne le pensez . Il existe également un plug-in Ruby on Rails appelé Juggernaut dont j'ai beaucoup entendu parler. Encore une fois, je ne l’ai pas utilisé, donc YMMV, mais je crois comprendre que cela prend beaucoup moins de ressources que les sondages. Je crois (quelqu'un peut-il confirmer?) Que COMET est le moyen par lequel MacRumorsLive.com publie des blogs en direct sur WWDC Stevenotes.