Wie werden gleichzeitige Anfragen in PHP gehandhabt (unter Verwendung von – Threads, Thread-Pool oder untergeordneten Prozessen)

Lesezeit: 7 Minuten


Ich verstehe, dass PHP die Verarbeitung mehrerer gleichzeitiger Verbindungen unterstützt und je nach Server wie in dieser Antwort erwähnt konfiguriert werden kann

Wie verwaltet der Server mehrere Verbindungen, verzweigt er einen untergeordneten Prozess für jede Anforderung oder verarbeitet er mithilfe von Threads oder verarbeitet er mithilfe eines Thread-Pools?

Die verknüpfte Antwort besagt, dass ein Prozess verzweigt ist, und dann sagt der Autor im Kommentar Threads oder Prozesse, was es verwirrend macht, wenn Anforderungen mit untergeordneten Prozessen, Threads oder Thread-Pools bedient werden?

  • [stackoverflow.com/questions/1623914/… , I think this is what you are looking for

    – anwerj

    Nov 10, 2015 at 7:30

user avatar

As I know, every webserver has it’s own kind of handling multpile simultanous request.
Usually Apache2 schould fork a child process for each new request. But you can somehow configure this behaviour as mentioned in your linked StackOverflow answer.

Nginx for example gets every request in one thread (processes new connections asyncronously like Node.js does) or sometimes uses caching (as configured; Nginx could also be used as a load balancer or HTTP proxy). It’s a thing of choosing the right webserver for your application.

Apache2 could be a very good webserver but you need more loadbalancing when you want to use it in production. But it also has good power when having multiply short lasting connections or even documents which don’t change at all (or using caching).

Nginx is very good if you expect many long lasting connections with somehow long processing time. You don’t need that much loadbalancing then.

I hope, I was able to help you out with this 😉




I recommend you to also look at: What is thread safe or non-thread safe in PHP?

  • I don’t fully get it in case of FastCGI, because FastCGI runs as a different application process how are threads/processes managed to handle incoming requests? My understanding is that in case of nginx, it itself won’t spawn a new thread/process in most cases, rather try to handle it in Node.js async fashion, but, how would the PHP FastCGI itself handle it – threads or will get blocked until previous requests are processed or it depends on PHP Application developer or a pre-forked process pool of FastCGI would be used?

    – prasun

    Dec 1, 2015 at 18:20

  • As Wikipedia states out at their FastCGI site, there already is a pool of processes hold by the FastCGI-Server to handle more than one request at once. This pool will be initialated when you startup your FastCGI-server.

    – jankal

    Dec 1, 2015 at 18:32

  • en.wikipedia.org/wiki/FastCGI look out for the “Implementation Details” section.

    – jankal

    Dec 1, 2015 at 18:34

  • there is a conflict though, “FastCGI applications can be single-threaded or multi-threaded. For single threaded applications, the Web server maintains a pool of processes (if the application is running locally) to handle client requests. The size of the pool is user configurable. Multi-threaded FastCGI applications may accept multiple connections from the Web server and handle them simultaneously in a single process” fastcgi.com/drupal/node/6?q=node/15

    – prasun

    Dec 1, 2015 at 18:37

  • how do we know how PHP Fast CGI binary works, I couldn’t find anything on that?

    – prasun

    Dec 1, 2015 at 18:38

user avatar

After doing some research I ended up with below conclusions.

It is important to consider how PHP servers are set to be able to get insights into it.For setting up the server and PHP on your own, there could be three possibilities:

1) Using PHP as module (For many servers PHP has a direct module interface (also called SAPI))

2) CGI

3) FastCGI

Considering Case#1 PHP as module, in this case the module is integrated with the web server itself and now it puts the ball entirely on web server how it handles requests in terms of forking process, using threads, thread pools, etc.

For module, Apache mod_php appears to be very commonly used, and the Apache itself handles the requests using processes and threads in two models as mentioned in this answer

Prefork MPM uses multiple child processes with one thread each and
each process handles one connection at a time.

Worker MPM uses
multiple child processes with many threads each. Each thread handles
one connection at a time.

Obviously, other servers may take other approaches but, I am not aware of same.

For #2 and #3, web server and PHP part are handled in different processes, and how a web server handles the request and how it is further processed by application(PHP part) varies. For e.g.: NGINX may handle the request using asynchronous non-blocking I/O and Apache may handle requests using threads, but, how the request would be processed by FastCGI or CGI application is a different aspect as described below. Both the aspects i.e. how web server handles requests and how PHP part is processed would be important for PHP servers performance.

Considering #2, CGI protocol has makes web server and application (PHP) independent of each other and CGI Protocol requires application and web server to be handled using different process and the protocol does not promote reuse of the same process, which in turn means a new process is required to handle each request.

Considering#3, FastCGI protocol overcomes the limitation of CGI by allowing process re-use. If you check IIS FastCGI link FastCGI addresses the performance issues that are inherent in CGI by providing a mechanism to reuse a single process over and over again for many requests.

FastCGI maintains compatibility with non-thread-safe libraries by
providing a pool of reusable processes and ensuring that each process
handles only one request at a time.

That said, in case of FastCGI it appears that the server maintains a process pool and it uses the process pool to handle incoming client requests and since, the process pool does not require thread safe check, it provides a good performance.

I think the answer depends on how the web server and the cgi deploy.

In my company, we use Nginx as the web server and php-fpm as cgi, so the concurrent request is handled as process by php-fpm, not thread.

We configure the max number of process, and each request is handled by a single php process, if more requests(larger than the max number of process) come , they wait.

So, I believe PHP itself can support all of them, but how to use it, that depends.

  • so, it is case of FastCGI and the reqeusts by PHP-fpm is handled using process pool with max number of processes as mentioned in my answer?

    – prasun

    Dec 4, 2015 at 6:05

  • ye, In my case, that’s exactly what I mean. But I am not sure in other web server how they use.

    – FisherMartyn

    Dec 4, 2015 at 6:07

  • This mostly cleared it up for me. when we say “as process” does that mean in a pipe, like packets in a chain, first come first serve, and the the lag time is the process lag time of the guy in front of you? e.g. 100 people hit 10 childs(static), 10 people are served immediately, the other 90 are waiting in cpu queue, 9 for each, etc.. right then? How does max_request come into play? i look at it just for respawning, e.g. if was set for say 10 then that thread re-spawns after its done serving its 10. I thought maybe you meant that by “max number processes”, maybe you meant childs

    – blamb

    Jan 27, 2021 at 22:50

user avatar
Yevgeniy Afanasyev

PHP does not handle requests. The web server does.

For Apache HTTP Server, the most popular is “mod_php”. This module is actually PHP itself, but compiled as a module for the web server, and so it gets loaded right inside it.

Since with mod_php, PHP gets loaded right into Apache, if Apache is going to handle concurrency using its Worker MPM (that is, using Threads)

For nginx PHP is totally outside of the web server with multiple PHP processes

It gives you choice sometimes to use non-thread safe or thread safe PHP.

But setlocale() function (when supported) is actually modifies the operation system process status and it is not thread safe.

You should remember it when you are not sure of how legacy code works.

1245100cookie-checkWie werden gleichzeitige Anfragen in PHP gehandhabt (unter Verwendung von – Threads, Thread-Pool oder untergeordneten Prozessen)

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy