Interrogation courte vs interrogation longue pour les applications Web en temps réel?
Je crée une application Web en temps réel Pour autant que je sache, les choix les plus populaires sont les sondages courts et les sondages longs. Quels pourraient être les avantages et les inconvénients de mesurer l'un par rapport à l'autre?
Interrogation courte (a.k.a. AJAX timer basé):
Avantages: plus simple, ne consomme pas de serveur (si le temps entre les requêtes est long).
Inconvénients: mauvais si vous devez être averti QUAND l'événement du serveur se produit sans délai. Exemple ( ItsNat basé)Long polling (alias Comet basé sur XHR)
Avantages: vous êtes averti QUAND l'événement du serveur se produit sans délai. Inconvénients: ressources plus complexes et plus utilisées. Exemple (basé sur ItsNat)
Juste pour les besoins de l'argument.
Les deux sont des requêtes http (xhr), et c'est au moins partiellement faux, il utilise plus de ressources serveur (dépend totalement de la technologie, expliquera plus tard).
Court sondage.
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-> Yeah. Have some lad.
00:00:03 C-> Is the other cake ready? ..
Interrogation longue
Une requête est envoyée au serveur et le client attend la réponse (son non résolu). Dans le cas d'un serveur avec php/Apache, cela signifierait un thread généré à gérer, qui réserve des ressources, jusqu'à ce qu'il soit fait. Le trafic est donc plus faible, mais vous mangez rapidement vos ressources (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 réduire considérablement l'utilisation des ressources (stocker l'objet de réponse pour la requête http et l'utiliser lorsque le le travail est prêt)
12:00 00:00:00 C-> Is the cake ready?
12:00 00:00:03 S-> Yeah.Hame some lad.
12:00 00:00:03 C-> Is the cake ready?
Si vous comparez cela à une courte interrogation, vous verrez que potentiellement dans une courte interrogation, vous avez utilisé plus de transfert, mais pendant ces 3 secondes, vous prenez en réalité 1,5 seconde de temps de traitement (ce qui signifie que quelque chose pourrait s'exécuter entre vos appels). Dans le cas d'un long sondage, les mêmes ressources étaient utilisées tout le temps. Maintenant, généralement php avec toutes les bibliothèques commence avec 4 Mo de mémoire - alors vous avez un framework 4-20 Mo. Supposons que vous disposez de 1024 Mo RAM disponible (gratuit). Disons que nous sommes pessimistes et supposons que vous utiliserez 25 Mo par instinct php. Cela signifie que vous ne pouvez obtenir que 40 scripts de connexion interrogés. .
C'est précisément la raison pour laquelle vous pourriez potentiellement servir beaucoup plus avec Node, car le nœud ne générerait pas ses instances (à moins que vous ne vouliez utiliser des travailleurs, etc.), donc avec la même mémoire, vous pourriez probablement facilement bloquer les connexions 10k. Vous obtiendriez un pic dans le processeur à mesure qu'ils arriveront, et quand ils seront potentiellement libérés, mais lorsqu'ils sont inactifs, c'est comme s'ils 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 peu de choses, à chaque fois qu'elles sont dans ou hors du client, optez pour les websockets (protocole ws). Le premier appel est de la taille de la requête http, mais plus tard vous n'envoyez que les messages, du client au serveur (nouvelles questions) et du serveur au client (réponses ou push - peut même diffuser pour tous les clients connectés). Il existe des bibliothèques php websocekts mais encore une fois, utilisez une technologie différente - nœud ou c ++ de préférence.
Certaines bibliothèques, comme socket.io, ont une hiérarchie qui leur est propre, donc lorsque websocket échoue, cela revient à une interrogation longue ou courte.
Quand utiliser.
sondage court - enfin, jamais ^^.
Interrogation longue - potentiellement lorsque vous échangez un seul appel avec le serveur et que le serveur effectue un travail en arrière-plan. De plus, lorsque vous n'interrogerez plus le serveur sur la même page. De plus, lorsque vous n'utilisez pas php comme couche pour gérer la longue connexion interrogée (node / c ++ peut être une simple couche intermédiaire). Notez que les longs sondages peuvent être vraiment bénéfiques, mais uniquement lorsque vous le faites.
Websocket - vous allez potentiellement échanger plus d'un ou deux appels avec le serveur, ou quelque chose pourrait provenir d'un serveur auquel vous ne vous attendiez pas/demandé, comme une notification par e-mail ou quelque chose. Vous devez planifier différentes "chambres", en fonction des fonctionnalités. Adoptez la nature événementielle de javascript;]
Si vous souhaitez 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 poll est vraiment bon pour votre bande passante et il est également très utile pour l'utilisateur MB.Parce que lorsque l'utilisateur envoie une demande, l'utilisateur paiera comme MB ou une sorte de connexion Internet.Par exemple pour Sondage court lorsque vous faites quelque chose comme l'envoi d'une demande par deuxième utilisateur, l'utilisation d'Internet sera plus importante car chaque utilisateur de connexion paiera pour cela (cela signifie que l'utilisateur perd du Mo) mais dans le long sondage, l'utilisateur ne paiera que pour les nouveaux messages .
Websocket est vraiment une bonne chose mais quand vous l'utilisez, vous devriez penser à un gros problème que beaucoup de gens ne peuvent pas utiliser le système de chat parce que Websocket n'est destiné qu'à une nouvelle version des navigateurs