Est-ce que php est évolutif avec reverse ajax long polling?

Je travaille sur un site Web qui affiche des données de la firebase database qui changent fréquemment (état d’une queue et d’une conversation de conversation). Ma configuration actuelle est Apache / PHP / MySQL. Naturellement, je voudrais éviter d’interroger le serveur toutes les x secondes, car cela ne fonctionne pas bien. Je voudrais faire une interrogation longue ajax, cependant, j’ai lu qu’Apache ne fonctionne pas bien avec cela car il est rapidement à court de threads de travail. Il existe de nombreux autres serveurs Web qui contournent ce problème: nginx, tornado, etc. Cependant, mon problème est que PHP est le seul langage de script côté serveur que je connaisse. De plus, j’ai déjà écrit des scripts PHP et je voudrais les conserver si je peux. Je suis bien avec le changement de serveur tant que je peux toujours utiliser PHP.

Mais après quelques recherches, je lis que les gens disent que PHP (PHP-FPM?) Crée également un processus pour chaque requête, ce qui signifie que si j’ai des centaines de milliers de connexions ouvertes, il y aura des centaines de milliers de processus. , qui sera aussi un problème.

Puis-je en conclure qu’il n’y a pas de moyen évolutif de faire de longs sites Web de sondage utilisant PHP? Dois-je abandonner PHP et apprendre un autre langage de script de serveur? Je peux continuer à développer une longue interrogation en utilisant ma configuration actuelle (Apache / PHP) pour le moment, mais je ne souhaite pas que le choix du langage de script limite l’extensibilité de mon système lors du déploiement. Donc qu’est ce que je devrais faire? Je ne suis pas très expérimenté en programmation web, donc si des gourous peuvent me donner des conseils, je l’apprécierais! Je vous remercie!

PHP exécuté en mode php-fpm aura toujours des limitations, surtout si votre code mange beaucoup de mémoire. Vous ne pourrez pas exécuter des milliers de processus parallèles sans mémoire disponible. Mais il fonctionne généralement plus vite que mod_php, et au moins les requêtes HTTP ne nécessitant pas PHP sont gérées par le serveur Web, et si ce serveur Web est nginx, vous obtiendrez beaucoup plus de requêtes HTTP en parallèle.

Avec php-fpm, vous aurez également une queue de requêtes en attente, ce qui peut être utile dans le cas d’un trafic important temporaire, car au moins les requêtes sont mises en queue et non rejetées.

Maintenant, les longues opérations d’interrogation sont correctes avec nginx (ou d’autres, c’est un exemple), mais pas avec PHP. PHP n’est pas conçu pour être un serveur de longue durée , chaque demande est un nouveau processus, ce n’est vraiment pas le bon choix pour une chose KeepAlive. Mais ” divise ut regnes ” (diviser pour régner). Vos longues tâches d’interrogation peuvent s’exécuter à proximité de votre application PHP, mais sans votre application PHP.

Par exemple, regardez le projet jappix , il s’agit d’un projet PHP. Mais vous devez placer quelque part un serveur XMPP (comme ejabberd) et un serveur BOSH avec nginx comme proxy sur le port 80 de ce serveur BOSH (vous avez donc le protocole de chat xmpp sur le port 80, via nginx et ejabberd, et rien sur le côté PHP pour ça). Le problème est alors de connecter l’authentification de votre application, son identification, etc., et cela en étendant la configuration du serveur XMPP (pour qu’il utilise le même serveur LDAP que votre application PHP par exemple).

Votre deuxième problème de longue durée est le statut d’une queue. Vous pouvez trouver des extensions XMPP pour cela, peut-être. Ou vous pouvez effectuer des requêtes ajax régulières sur la queue. Une des techniques utiles pour éviter le grand nombre de requêtes ajax sur votre application PHP est de replanifier la prochaine vérification ajax sur le rappel ajax du chèque, en fonction des nombres de Fibonacci (c’est un exemple). Donc, la première fois que le prochain appel ajax sera programmé 1 minute après, la prochaine fois 2 minutes, puis 3m, 5m, 8m, 13m, 21m, 34m, 55m, 89m, 144m, etc. nouveaux messages entrants 1 minute après le chargement d’une page. Comme l’utilisateur lit toujours la même page (ou boit un café, parle à un ami, va en vacances sans éteindre son ordinateur, etc.), nous pouvons retarder de plus en plus les contrôles suivants. Est-ce un moyen de supposer que l’utilisateur n’est pas vraiment actif. Notez que vous pouvez détecter l’activité de l’utilisateur par d’autres moyens et modifier la reprogrammation.

PHP n’est pas adapté aux longues interrogations, aux technologies Comet et Reverse Ajax. Vous devriez utiliser Node.js