Les Websockets avez un couple de grands inconvénients en termes d'évolutivité ajax évite. Depuis ajax envoie une requête/réponse et ferme la connexion (..ou peu de temps après) si quelqu'un reste sur la page web, il n'utilise pas les ressources du serveur lors de la marche au ralenti. Les Websockets sont destinés à des flux de données vers le navigateur, et ils sont à égalité de ressources sur le serveur pour le faire. Les serveurs ont une limite dans le nombre de connexions simultanées qu'ils peuvent garder ouverts en même temps. Pour ne pas mentionner en fonction de votre côté serveur de la technologie, ils peuvent attacher un thread pour gérer la prise de courant. Donc websockets ont plus de ressources exigences pour les deux côtés par connexion. Vous pouvez facilement épuiser tous vos threads service des clients, et puis pas de nouveaux clients à venir en si grand nombre d'utilisateurs sont assis sur la page. C'est là que nodejs, vertx, netty peuvent vraiment aider, mais même ceux qui ont des limites supérieures.
Il y a aussi la question de l'état de la socket sous-jacente, et de l'écriture du code sur les deux côtés qui portent sur la dynamique de la conversation, ce qui n'est pas quelque chose que vous avez à faire avec ajax style parce que c'est apatride. Les Websockets exiger de vous que vous créez un faible niveau de protocole qui est résolu pour vous avec l'ajax. Des choses comme le cœur battant, la fermeture des connexions inactives, de la reconnexion en cas d'erreur, etc, sont d'une importance vitale maintenant. Ce sont des choses que vous n'avez pas à résoudre lors de l'utilisation d'AJAX, car il était apatride. L'état est très important pour la stabilité de votre application et surtout la santé de votre serveur. Il n'est pas trivial. Pré-HTTP, nous avons construit beaucoup de dynamique protocoles TCP (FTP, telnet, SSH), puis l'adresse HTTP qui s'est passé. Et personne n'a ce genre de choses beaucoup plus car même avec ses limites HTTP a été étonnamment plus facile et plus robuste. Les Websockets ramener le bon et le mauvais de la dynamique des protocoles. Vous apprendrez assez vite, si vous n'obtenez pas une dose de ce dernier tour.
Si vous avez besoin de streaming en temps réel des données de cette surcharge est justifié en raison de l'interrogation du serveur pour obtenir des données en streaming est pire, mais si tout ce que vous faites est d'interaction de l'utilisateur->request->response->mise à jour de l'INTERFACE utilisateur, puis ajax est plus facile et moins d'utilisation des ressources, car une fois que la réponse est envoyée la conversation est terminée et aucun serveur supplémentaire les ressources sont utilisées. Donc, je pense que c'est un compromis, et que l'architecte doit choisir l'outil qui convient à leur problème. AJAX a sa place, et les websockets ont leur place.
Mise à jour
Si l'architecture de votre serveur est tout ce qui compte quand on parle de threads. Si vous utilisez une tradition multi-thread du serveur (ou de processus) où chaque connexion de socket obtient son propre thread pour répondre à des demandes puis les websockets sont très importantes pour vous. De sorte que pour chaque connexion, nous avons une socket, et, finalement, le système d'exploitation va tomber, si vous avez trop plusieurs d'entre eux, et va de même pour les threads (et plus pour les processus). Les Threads sont plus lourds que les sockets (en termes de ressources), donc nous essayons de conserver le nombre de threads que nous avons en cours d'exécution simultanément. Que signifie la création d'un pool de threads qui est juste un nombre fixe de threads qui sont partagées entre tous les sockets. Mais une fois la socket est ouvert le thread est utilisé pour l'ensemble de la conversation. La longueur de ces conversations régissent la façon dont rapidement vous pouvez réutiliser ces threads pour les nouveaux sockets à venir. La durée de votre conversation régit la façon dont beaucoup vous pouvez mettre à l'échelle. Toutefois, si vous êtes en streaming ce modèle ne fonctionne pas bien pour la mise à l'échelle. Vous devez casser le fil/prise de conception.
HTTP de la requête/réponse modèle le rend très efficace dans la transformation de plus de threads pour les nouveaux sockets. Si vous avez l'intention d'utiliser de requête/réponse HTTP de son déjà construit et beaucoup plus facile que de réimplanter quelque chose comme ça dans les websockets.
Depuis les websockets n'avez pas à être de requête/réponse HTTP et peut diffuser des données si votre serveur dispose d'un nombre fixe de threads dans son pool de threads et vous avez le même nombre de websockets monopoliser toutes vos discussions avec des conversations actives, vous ne pouvez pas en service de nouveaux clients à venir! Vous avez atteint votre maximum de sa capacité. C'est là une conception de protocole est trop important avec les websockets et les threads. Votre protocole peut vous permettre de desserrer le fil par prise par la conversation modèle de cette façon, les gens assis là, à ne pas utiliser un thread sur votre serveur.
C'est là que asynchrone seul thread serveurs. En Java, on appelle souvent ce NIO pour les non-bloquant IO. Cela signifie que c'est une API différente pour les sockets d'où l'envoi et la réception de données à ne pas bloquer le thread d'exécution de l'appel.
De manière traditionnelle dans des sockets blocage lorsque vous appelez le support.read() ou la prise.write (), ils attendent jusqu'à ce que les données sont reçues ou envoyées avant de rendre le contrôle de votre programme. Cela signifie que votre programme est bloqué en attente pour la prise de données pour entrer ou sortir jusqu'à ce que vous pouvez faire autre chose. C'est pourquoi nous avons threads de sorte que nous pouvons faire travailler simultanément (en même temps). Envoyer ces données au client X pendant que j'attends sur les données du client Y. accès simultanés est le nom du jeu quand on parle de serveurs.
Dans un NIO serveur, nous utilisons un seul thread pour gérer tous les clients et d'enregistrer des rappels pour être averti lorsque les données arrivent. Par exemple
socket.read( function( data ) {
// data is here! Now you can process it very quickly without waiting!
});
Le socket.lire() va retourner immédiatement, sans la lecture de toutes les données, mais notre fonction, nous avons fourni sera appelée quand elle vient. Cette conception radicalement changer la façon dont vous construisez et l'architecte de votre code, parce que si vous vous attardez attente sur quelque chose que vous ne pouvez pas recevoir de nouveaux clients. Vous disposez d'un seul fil, vous ne pouvez vraiment pas faire deux choses à la fois! Vous devez garder qu'un seul thread en mouvement.
NIO, Asynchrone IO, basée sur les Événements du programme comme cela est connu sous le nom, est beaucoup plus compliqué que la conception du système, et je ne voudrais pas vous suggère de l'essayer et d'écrire cela si vous êtes débutant. Même les très Hauts programmeurs trouver qu'il est très difficile d'acquérir de solides systèmes. Puisque vous êtes asynchrone, vous ne pouvez pas appeler les Api de ce bloc. Comme la lecture des données à partir de la DB ou l'envoi de messages à d'autres serveurs doivent être effectuées de manière asynchrone. Même la lecture et l'écriture dans le système de fichiers peut ralentir votre seul fil vers le bas pour abaisser votre évolutivité. Une fois que vous allez asynchrone, tout est asynchrone tout le temps si vous voulez garder le thread unique mouvement. C'est ce qui est difficile, parce que finalement, vous allez lancer dans une API, comme DBs, qui n'est pas asynchrone et que vous avez à adopter de plus en plus de fil à un certain niveau. Ainsi, une approche hybride sont fréquents, même dans le asynchrones monde.
La bonne nouvelle est qu'il y a d'autres solutions que d'utiliser ce faible niveau de l'API déjà intégré que vous pouvez utiliser. NodeJS, Vertx, Netty, Apache Mina, Play Framework, Twisted Python, Stackless Python, etc. Il y a peut être quelque obscure de la bibliothèque pour le C++, mais honnêtement, je ne serais pas la peine. La technologie de serveur ne nécessite pas les plus rapides langues parce que c'est IO lié plus qu'en CPU. Si vous êtes un die hard performance de l'écrou de l'utilisation de Java. Il a une énorme communauté de code pour tirer à partir et c'est la vitesse est très proche (et parfois mieux) que le C++. Si vous détestez aller avec Nœud ou Python.
