streaming une option viable? Y aura-t-il une différence de performance sur la fin du serveur en fonction de laquelle je choisis? est un meilleur que l'autre pour ce cas?
Je travaille sur une application GWT avec Tomcat en cours d'exécution sur la fin du serveur. Pour comprendre mes besoins, imaginez une mise à jour des prix des actions de plusieurs stocks simultanément.
6 Réponses :
Voulez-vous que le processus soit dirigé par le client ou le serveur? En d'autres termes, voulez-vous appuyer sur les nouvelles données aux clients dès qu'il sera disponible ou préféreriez-vous que les clients demandent de nouvelles données chaque fois qu'ils voient, même si cela pourrait ne pas être une fois / seconde? Quelle est la probabilité que le client puisse rester pour attendre une réponse? Même si vous vous attendez à ce que les événements se produisent une fois / seconde, combien de temps faut-il entre une demande d'un client et le retour du serveur? Si cela est plus long qu'une seconde, je m'attendais à ce que vous penchiez vers vous pour pousser les événements aux clients, bien que l'inverse, je m'attendais à ce que l'interrogation soit correct. Si la réponse prend plus de temps que l'intervalle, vous êtes essentiellement en streaming de toute façon, car il y a un nouvel événement prêt au moment où le client reçoit le dernier, le client pourrait donc essentiellement sonder continuellement et toujours recevoir des événements - dans ce cas, en streaming Les données seraient effectivement plus légères, car vous retirez la transmission de la connexion / des négociations du processus.
Je soupçonnerais que le serveur charge soit plus élevé pour une abonnement basé sur le client (tirant), au lieu d'une configuration de diffusion en continu, car le client devrait réinsertionner la connexion à chaque fois, au lieu de laisser une connexion ouverte, mais Chaque connexion ouverte dans un modèle de streaming nécessiterait également des ressources de serveur. Cela dépend de ce que le compromis est entre la manière dont votre processus de négociation est agressif vs. Quelle quantité de mémoire / traitement est requise pour chaque connexion ouverte. Je ne suis pas expert, cependant, il peut y avoir d'autres facteurs.
mise à jour: Ce gars parle du commerce des offs entre le sondage long et le streaming, et il semble dire qu'avec http / 1.1, le processus de réintention de la connexion est trivial, ce n'est pas autant d'un problème.
Hey Rwmnau, le lien que vous avez fourni est illuminant. Pour répondre à vos questions, je voudrais appuyer sur les données aux utilisateurs dès qu'il sera disponible.
Si vous souhaitez appuyer sur les données aux utilisateurs dès que vous le pouvez, je pense que le choix doit être en continu, car cela maintiendra une connexion à base de poussée. Avec une configuration de tirage, vous attendez que les clients demandent, mais avec des poussées, ils auront les données dès que vous leur donnez. Laissez-moi savoir ce que vous finissez par choisir et pourquoi!
Certainement, si vous cherchez à pousser des données, la diffusion en continu semblerait fournir de meilleures performances, si votre serveur peut gérer le nombre de connexions continues prévu. Mais il y a un autre problème que vous n'ayez pas adressé: êtes-vous internet ou intranet? Le streaming a été signalé avoir des problèmes sur les proxies, autant que vous vous attendez. Donc, pour une solution à usage général, vous seriez probablement mieux servi par long sondage - pour un intranet, où vous comprenez l'infrastructure de réseau, la diffusion en continu est probablement une solution de performance plus simple et plus simple pour vous.
Streaming sera plus rapide car les données n'écrument que le fil d'une manière. Avec le sondage, la latence est au moins deux fois.
Le sondage est plus résilient sur les pannes de réseau car il ne s'appuie pas sur une connexion étant maintenue ouverte.
J'irais un sondage juste pour la robustesse.
J'aimerais préciser que ma question concerne de longues interrogations et non traditionnelles. En outre, Nio devrait être une donnée.
Vous avez raison, Nio brise le fil par restriction de connexion, atténuant l'exigence de fil.
Pour les cours des actions en direct, je garderais absolument la connexion ouverte et assurera une alerte utilisateur / la reconnexion sur la déconnexion.
the StreamHub GWT Comet Adapter a été conçu exactement pour ce scénario de Streaming Citations de stock. Exemple ici: Stock de streaming GWT Citations . Il met à jour les prix des actions de plusieurs stocks simultanément. Je pense que la mise en œuvre en dessous est la comète qui streaming essentiellement sur http.
Edit: il utilise une technique différente pour chaque navigateur. Pour citer le site Web:
Il y a plusieurs sous-jacents différents Techniques utilisées pour implémenter la comète y compris iframe caché, XMLHTTPQUEST / Script Long Bonding, et des plugins intégrés tels que Flash. L'introduction de HTML 5 WebSockets dans les navigateurs futurs fourniront un Mécanisme alternatif pour http Diffusion. StreamHub utilise un "meilleur ajustement" approche utilisant le plus performant et technique fiable pour chaque Navigateur.
Cela n'a pas vraiment d'importance. La ré-négociation de connexion est tellement mince avec http1.1, vous remarquerez des différences de performance significatives d'une manière ou d'une autre.
Les avantages de l'interrogation de longue durée sont la compatibilité et la fiabilité - pas de problèmes avec les procurations, les ports, la détection de déconnectes, etc.
Les avantages du streaming "vrai" serait potentiellement réduit les frais généraux, mais comme mentionné déjà, cet avantage est beaucoup, beaucoup moins que ce qu'il est fabriqué à être.
Personnellement, je trouve un serveur Comet bien conçu pour être la meilleure solution pour un grand nombre de mises à jour et / ou de la poussée du serveur.