Mise à l'échelle d'une application de chat - interrogation courte vs interrogation longue (AJAX, PHP)

Question

Je lance un site web où les utilisateurs peuvent communiquer les uns avec les autres via le navigateur (pensez à Facebook chat). Quelle est la meilleure façon de gérer l'interaction en direct? (En ce moment j'ai un sondage passe toutes les 30 secondes pour mettre à jour les utilisateurs en ligne et la réception de nouveaux messages, et un autre sondage, allez sur le chat pages à chaque seconde pour obtenir de nouveaux messages.)

Les choses que j'ai vu:

• Websockets HTML5: ne pas l'utiliser car il ne fonctionne pas dans tous les navigateurs (uniquement chrome).
• Flash Sockets: ne pas l'utiliser parce que je voulais finalement, support web mobile.

Maintenant, je suis à l'aide d'interrogation court parce que je ne sais pas comment évolutive AJAX d'interrogation serait. Je fais tourner un serveur VPS de servint droit maintenant (apache). Dois-je utiliser le temps d'interrogation ou d'interrogation court? Je n'ai pas besoin absolument immédiate, les temps de réponse (juste assez "bon" pour une application de chat). Est à court d'interrogation de ce souvent avec quelques centaines de milliers d'utilisateurs en vais tuer mon serveur? Comment puis-je l'appliquer à grande échelle, s'il vous plaît aider!

Answer 1

Quelques remarques:

• D'interrogation à chaque seconde, c'est du matraquage. L'application va encore se sentir très à l'écoute avec quelques secondes de délai entre deux vérifications.
• Pour enregistrer votre base de données de trafic et de la vitesse des réponses, pensez à utiliser une mémoire cache pour stocker les messages non livrés. Vous pourriez persistent encore des messages à la db, la mémoire cache serait tout simplement être utilisé pour les requêtes de nouveaux messages pour éviter les requêtes à la base de données toutes les x secondes par chaque utilisateur.
• Délai d'attente de l'utilisateur de chat après x secondes d'inactivité pour arrêter de vote à votre serveur. Ceci garantit à quelqu'un en laissant une fenêtre ouverte ne pourra pas continuer à générer du trafic. Proposer un simple "Toujours là? Continuer à chatter." lien pour les séances de délai d'attente et d'avertir l'utilisateur avant le délai d'expiration, de sorte qu'ils peuvent prolonger le délai d'attente.
• Je vous suggère de commencer avec interrogation plutôt que de comète/interrogation/sockets. L'interrogation est simple à construire et à du soutien et sera susceptible de l'échelle très bien dans le court terme. Si vous avez beaucoup de trafic, vous pouvez jeter un matériel et un équilibreur de charge sur le problème à l'échelle. L'ensemble du web est basé sur des bureaux de scrutin le plus certainement échelles. Il y a un point où la complexité des solutions de rechange, comme la comète/interrogation/etc font sens, mais vous avez besoin de beaucoup de trafic avant que le supplément de temps de développement et la complexité sont justifiées.

Answer 2

C'est quelque chose que tout le monde a fait une fois, avant l'introduction de cometd et nodejs.

Le problème que je vois c'est les requêtes PHP sur Apache sont très coûteux. Si votre application de chat vérifie les messages à chaque seconde, vous vous trouvez dans une situation où l'Apache n'ont pas assez de ressources pour répondre aux demandes. L'autre domaine, je pense, besoin d'amélioration est d'améliorer le cadre de votre application de chat.

Pourquoi faut-il mettre à jour à chaque seconde si ce n'est pour récupérer les nouveaux messages? Que faire si il n'y a pas de messages?

Quelques techniques que vous pouvez utiliser;

• Fournir une légèreté et un point de terminaison de vos clients de a quelques le contexte de la session de chat, est un nouveau message en attente, combien de messages, etc. Le client peut répondre à cette par la mise à jour immédiatement ou pas, si il n'y a pas de nouveaux messages. De ce point de terminaison peut fournir un simple objet json via une requête http. Vous avez la garantie que ce message d'état est d'une taille fixe et si la réponse de l'état ne change pas, vous pouvez décomposition, il. Voir le message suivant.

• Une simple carie dans l'option javascript de votre interrogation, si le client reçoit la même réponse du serveur à quelques reprises dans une rangée, vous pouvez incrémenter le sondage par un temps de jeu, à l'heure actuelle vous a dit que c'était à chaque seconde. Si vous avez fait cela, vous devez incrémenter à chaque 2,4,6,8,10 secondes. Dès que la réponse du serveur change, la réinitialisation de la décroissance.

Quelques optimisations à prendre en compte;

• Utilisez PHP cache d'Opcode comme APC.

• Un faible délai d'attente sur toutes les demandes, vous ne voulez pas de demandes d'accrocher votre serveur.

• Optimiser votre code PHP, le rendre léger et rapide.

• Exécuter certains tests de charge pour voir ce que vos limites.

• Performance de référence afin de s'assurer que vos applications est de plus en plus rapides.

• Vérifier les logs apache pour tell tale signs de la santé globale de l'application et le temps de réponse.

Lors de la mise à l'échelle est nécessaire, ajouter un nouveau serveur et d'utiliser un équilibreur de charge pour distribuer les demandes. J'ai utilisé de Vernis et HAProxy avec beaucoup de succès, leur mise en place n'est pas compliqué non plus.

Answer 3

Si j'étais vous, je choisirais une bibliothèque qui utilise les sockets web html5 mais retombe sur les sockets flash si html5 n'est pas disponible, le navigateur qui tombe à travers la fissure devrait être infime.

Vous devez également abandonner php ou le compléter avec un serveur de socket fileté écrit en python ou ruby avec em-websocket.