Comment puis-je résoudre le problème c10k si j'utilise PHP?

Question

Je décide de l'architecture d'une application où "Http KeepAlive" et "long polling" seront utilisés pour une réponse plus rapide. Y at-il quelque chose pour PHP qui résout le problème que Tornado fait pour C10K? Je pensais utiliser nginx + PHP-FPM. Mais alors, pour 1000 connexions actives, y aura-t-il 1000 processus PHP-FPM?

Ensuite, je pense que nous aurons le même problème qu'Apache a avec de nombreuses connexions permanentes. N'est-ce pas?

EDIT: Je comprends que nginx sera suffisant si je veux juste HTTP KeepAlive. Mais que se passe-t-il si je veux aussi un long sondage comme les supports de tornade? Y a-t-il quelque chose de similaire en PHP?

Answer 1

Je ne comprends pas ce que vous voulez dire. le c10k est lié au serveur web (apache, nginx etc) pas à PHP.

Si vous utilisez Nginx ne vous inquiétez pas à ce sujet

Answer 2

Pour les connexions actives (comme, le chargement et l'exécution d'un script PHP défini), oui, il y aura autant de processus PHP comme actives connexions. Mais KeepAlive est environ passive connexions, et Nginx est très bon à gérer les connexions passives KeepAlive avec une très faible utilisation des ressources - même pour des milliers d'entre eux. Le problème avec Apache est que, dans la configuration habituelle avec mod_php et mpm_prefork, il a besoin d'un processus pour chaque connexion, même s'il s'agit d'un KeepAlive passif. Cela signifie que la plupart des serveurs Apache ont besoin d'avoir un processus PHP en mémoire même si la connexion est passive, mais ce n'est pas le cas si vous utilisez PHP en FastCGI. Apache peut également gérer beaucoup de connexions passives si vous exécutez PHP en tant que FastCGI et choisissez le mpm_worker qui créera un thread plus léger par connexion, mais ce n'est pas encore aussi bon que Nginx.

Answer 3

Ma réponse à ce serait de jeter un oeil à node.js, Vous spécifiez une connexion 100K Active que Node.js devrait gérer très bien tant que vous avez le bon matériel. Le noeud ne génère pas de nouveaux processus lorsqu'une connexion est établie, le socket est placé dans un système de mise en file d'attente mais ce n'est pas un système de mise en file d'attente typique, où 1 connexion est traitée et la suivante. Node.js est connu pour gérer de nombreuses connexions et HTTP Client Library est basé sur le style de transfert Keep-Alive, tout en étant très rapide et puissant.

Je l'ai utilisé un peu et je dois dire qu'il est extrêmement facile à utiliser, il est basé sur le moteur Google V8 Super rapide qui est utilisé pour le JavaScript dans Chrome, ce qui signifie qu'il est extrêmement rapide, vous devriez vraiment jeter un oeil à ce sujet et vous verrez que c'est viable pour ce genre de chose.

• Blog post about Plurk using Node.js
• Plurk handling 100.000+ open Connections