comment les requêtes simultanées sont-elles traitées dans PHP (en utilisant - threads, pool de threads ou processus enfants)
Je comprends que PHP prend en charge la gestion de plusieurs connexions simultanées et en fonction du serveur, il peut être configuré comme mentionné dans ce réponse
Comment le serveur gère-t-il plusieurs connexions, il crée un processus enfant pour chaque demande ou gère-t-il à l'aide de threads ou gère-t-il à l'aide d'un pool de threads?
Le réponse liée indique qu'un processus est bifurqué, puis l'auteur en commentaire dit les threads ou le processus, ce qui le rend confus, si les demandes sont servies en utilisant des processus enfants, des threads ou un pool de threads?
Comme je le sais, chaque serveur Web a son propre type de traitement des demandes simultanées à plusieurs piles. Habituellement, Apache2 devrait créer un processus enfant pour chaque nouvelle demande. Mais vous pouvez en quelque sorte configurer ce comportement comme mentionné dans votre réponse StackOverflow liée.
Nginx, par exemple, obtient chaque demande dans un seul thread (traite les nouvelles connexions de manière asynchrone comme le fait Node.js) ou utilise parfois la mise en cache (telle que configurée; Nginx peut également être utilisé comme équilibreur de charge ou proxy HTTP). Il s'agit de choisir le bon serveur Web pour votre application.
Apache2 pourrait être un très bon serveur Web, mais vous avez besoin de plus d'équilibrage de charge lorsque vous souhaitez l'utiliser en production. Mais il a également un bon pouvoir lorsque vous multipliez les connexions de courte durée ou même les documents qui ne changent pas du tout (ou en utilisant la mise en cache).
Nginx est très bon si vous vous attendez à de nombreuses connexions durables avec un temps de traitement en quelque sorte long. Vous n'avez alors pas besoin de beaucoup d'équilibrage de charge.
J'espère que j'ai pu vous aider avec ça;)
Sources:
https://httpd.Apache.org/docs/2.4/mod/worker.html
https://anturis.com/blog/nginx-vs-Apache/
Je vous recommande également de regarder: Qu'est-ce qui est thread-safe ou non-thread safe en PHP?
Après avoir fait quelques recherches, je me suis retrouvé avec les conclusions ci-dessous.
Il est important de considérer comment les serveurs PHP sont configurés pour être en mesure d’obtenir des informations sur celui-ci. Pour configurer le serveur et PHP par vous-même, il pourrait y avoir être trois possibilités:
1) Utilisation de PHP comme module (pour de nombreux serveurs PHP possède une interface de module directe (également appelée SAPI)))
2) CGI
3) FastCGI
Considérant le cas # 1 PHP comme module, dans ce cas, le module est intégré au serveur Web lui-même et maintenant il met entièrement la balle sur le serveur Web comment il gère les demandes en termes de processus de forking, en utilisant threads, pools de threads, etc.
Pour le module, Apache mod_php semble être très couramment utilisé, et l'Apache lui-même gère les demandes en utilisant des processus et des threads dans deux modèles comme mentionné dans ce answer
Prefork MPM utilise plusieurs processus enfants avec un thread chacun et chaque processus gère une connexion à la fois.
Worker MPM utilise plusieurs processus enfants avec de nombreux threads chacun. Chaque thread gère une connexion à la fois.
Évidemment, d'autres serveurs peuvent adopter d'autres approches, mais je n'en suis pas conscient.
Pour # 2 et # 3, le serveur Web et la partie PHP sont traités dans différents processus, et la façon dont un serveur Web gère la demande et la façon dont elle est traitée par l'application (partie PHP) varie. Pour Par exemple: NGINX peut gérer la demande à l'aide d'E/S asynchrones non bloquantes et Apache peut gérer les demandes à l'aide de threads, mais la façon dont la demande serait traitée par FastCGI ou l'application CGI est un aspect différent, comme décrit ci-dessous. Le serveur gère les requêtes et la façon dont PHP partie est traitée serait important pour PHP les performances des serveurs.
Considérant # 2, le protocole CGI a rendu le serveur Web et l'application (PHP) indépendants les uns des autres et le protocole CGI exige que l'application et le serveur Web soient gérés en utilisant un processus différent et le protocole ne favorise pas la réutilisation du même processus, ce qui signifie à son tour une un nouveau processus est requis pour traiter chaque demande.
Considérant # 3, le protocole FastCGI surmonte la limitation de CGI en permettant la réutilisation des processus. Si vous cochez lien IIS FastCGI FastCGI résout les problèmes de performances inhérents à CGI en fournissant un mécanisme permettant de réutiliser un seul processus encore et encore pour de nombreuses demandes.
FastCGI maintient la compatibilité avec les bibliothèques non thread-safe en fournissant un pool de processus réutilisables et en s'assurant que chaque processus ne gère qu'une seule demande à la fois.
Cela dit, dans le cas de FastCGI, il semble que le serveur gère un pool de processus et qu'il utilise le pool de processus pour gérer les demandes clientes entrantes et puisque, le pool de processus ne nécessite pas de vérification sécurisée des threads, il offre de bonnes performances.
Je pense que la réponse dépend de la façon dont le serveur Web et le cgi se déploient.
Dans mon entreprise, nous utilisons Nginx comme serveur Web et php-fpm comme cgi, donc la requête simultanée est traitée comme un processus par php-fpm, pas par thread.
Nous configurons le nombre maximal de processus, et chaque demande est traitée par un seul processus php, si plus de demandes (plus grandes que le nombre maximal de processus) arrivent, elles attendent.
Donc, je crois que PHP lui-même peut les supporter tous, mais comment l'utiliser, cela dépend.
PHP ne gère pas les demandes. Le serveur Web le fait.
Pour Apache HTTP Server, le plus populaire est "mod_php". Ce module est en fait PHP lui-même, mais compilé en tant que module pour le serveur Web, et donc il est chargé directement à l'intérieur.
Depuis avec mod_php, PHP est chargé directement dans Apache, si Apache va gérer la concurrence en utilisant son Worker MPM (c'est-à-dire en utilisant Threads)
Pour nginx PHP est totalement en dehors du serveur Web avec plusieurs PHP processus
Il vous donne parfois le choix d'utiliser non-thread safe ou thread safe PHP.
Mais la fonction setlocale () (lorsqu'elle est prise en charge) modifie en fait l'état du processus du système d'exploitation et n'est pas sûre pour les threads.
Vous devez vous en souvenir lorsque vous n'êtes pas sûr du fonctionnement du code hérité.