Je construis une application web en temps réel Pour autant que je sache, les choix les plus populaires sont le sondage court et le sondage long. Quels sont les avantages et les inconvénients de mesurer l'un plutôt que l'autre ?
Réponses
Trop de publicités?
sp3c1
Points
370
Juste pour le plaisir d'argumenter.
Les deux sont des requêtes http (xhr), et il est au moins partiellement faux qu'elles utilisent plus de ressources serveur (cela dépend totalement de la technologie, je l'expliquerai plus tard).
Un sondage court.
Beaucoup de demandes qui sont traitées au fur et à mesure qu'elles arrivent sur le serveur. Crée beaucoup de trafic (utilise des ressources, mais les libère dès que la réponse est renvoyée) :
00:00:00 C-> Is the cake ready?
00:00:01 S-> No, wait.
00:00:01 C-> Is the cake ready?
00:00:02 S-> No, wait.
00:00:02 C-> Is the cake ready?
00:00:03 S-> Yes. Have some lad.
00:00:03 C-> Is the other cake ready? ..Longs scrutins
Une demande est envoyée au serveur et le client attend la réponse (non résolue). Dans le cas d'un serveur avec php/apache, cela signifie qu'un fil d'exécution est créé pour gérer le processus, qui réserve des ressources, jusqu'à ce qu'il soit terminé. Le trafic est donc plus faible, mais vous consommez vos ressources rapidement (ou plutôt vous bloquez les ressources). Mais si vous utilisez par exemple Node (ou toute autre approche asynchrone - c++ qt par exemple), vous pouvez potentiellement minimiser l'utilisation des ressources (stocker l'objet de réponse pour la requête http et l'utiliser lorsque le travail est prêt).
12:00 00:00:00 C-> Is the cake ready?
12:00 00:00:03 S-> Yes.Have some lad.
12:00 00:00:03 C-> Is the cake ready? Si vous comparez cela au polling court, vous verrez que potentiellement, dans le polling court, vous utilisez plus de transfert, mais pendant ces 3s vous prenez en fait 1,5s de temps de traitement (ce qui signifie que quelque chose pourrait s'exécuter entre vos appels). Dans le cas d'un sondage long, les mêmes ressources sont utilisées tout le temps. En général, php avec toutes les librairies démarre avec 4MB de mémoire - puis vous avez un framework de 4-20MB. Supposons que vous ayez 1024MB de RAM disponible (libre). Soyons pessimistes et supposons que vous utiliserez 25 Mo par installation de php. Cela signifie que vous ne pouvez pas obtenir plus de 40 longs scripts de connexion polled.
C'est précisément la raison pour laquelle vous pourriez potentiellement servir beaucoup plus avec Node, puisque Node ne génère pas ses instances (à moins que vous ne vouliez utiliser des travailleurs etc.), donc avec la même mémoire vous pourriez probablement obtenir facilement 10k connexions suspendues. Vous obtiendrez un pic dans le CPU quand elles viendront, et quand elles seront potentiellement libérées, mais quand elles sont inactives, c'est comme si elles n'étaient pas là (vous ne payez que pour les structures de mémoire que vous conserveriez dans node/c++).
Websocket
Maintenant, si vous voulez envoyer quelques éléments, à chaque fois qu'ils sont dans ou hors du client, optez pour les websockets (protocole ws). Le premier appel est de la taille d'une requête http, mais plus tard vous envoyez juste les messages, du client au serveur (nouvelles questions) et du serveur au client (réponses ou poussées - peut même faire une diffusion pour tous les clients connectés). Il existe des librairies php websocekts mais là encore, il faut utiliser une technologie différente - node ou c++ de préférence.
Certaines librairies, comme socket.io, ont leur propre hiérarchie, de sorte que lorsque websocket échoue, il revient à une interrogation longue ou courte.
Quand l'utiliser.
Sondage court - Eh bien, jamais ^^.
Longs scrutins - potentiellement lorsque vous échangez un appel unique avec le serveur, et que le serveur effectue un travail en arrière-plan. De même, lorsque vous n'interrogez plus le serveur sur la même page. Aussi lorsque vous n'utilisez pas php comme couche pour gérer la connexion longuement interrogée (node/c++ peut être une simple couche intermédiaire). Notez que l'interrogation longue peut être vraiment bénéfique, mais seulement si vous le faites.
Websocket - vous allez potentiellement échanger plus d'un ou deux appels avec le serveur, ou quelque chose pourrait venir du serveur que vous n'attendiez pas / n'aviez pas demandé, comme la notification d'un e-mail ou autre. Vous devez prévoir différentes "pièces", en fonction des fonctionnalités. Adoptez la nature événementielle de javascript ;]
-
Sondage court (a.k.a. minuterie basée sur AJAX) :
Avantages : plus simple, ne consomme pas de serveur (si le temps entre les requêtes est long).
Contre : mauvais si vous avez besoin d'être notifié QUAND l'événement du serveur se produit sans délai. Exemple ( ItsNat basé) -
Long polling (a.k.a. Comet basé sur XHR)
Pour : vous êtes notifié QUAND l'événement serveur se produit, sans délai. Contre : plus complexe et plus de ressources serveur utilisées. Exemple (basé sur ItsNat)
Ibrahim Hasanov
Points
88
Si vous voulez obtenir une application en temps réel basée sur une base de données, vous pouvez utiliser la combinaison ajax long poll et comet. Long sondage est très bon pour votre bande passante et aussi très utile pour le MB de l'utilisateur, car lorsque l'utilisateur envoie une demande, il paie pour cela comme un MB ou une sorte de connexion internet. Petit sondage Quand vous faites quelque chose comme envoyer une demande par seconde, l'utilisation de l'internet par l'utilisateur sera plus importante car chaque connexion sera payante (ce qui signifie que l'utilisateur perd du Mb), mais à long terme, l'utilisateur ne paiera que pour les nouveaux messages.
Websocket est une très bonne chose mais lorsque vous l'utilisez, vous devez penser à un gros problème : beaucoup de personnes ne peuvent pas utiliser le système de chat parce que Websocket est réservé aux nouvelles versions des navigateurs.
