How does the PHP core handle client connections?

Question

As far as I know, for each client connected to the server, PHP generates a new thread for it. But I wonder if this is true or not, and if it is true, how long does this stream survive? Does this thread support all static variables correctly? (e.g. database connection)

When this thread is destroyed, does it call all destructors?

Answer 1

It all depends on how PHP is configured with the server. I am familiar with Apache / PHP combos (not Nginx and FastCGI with PHP settings), so focusing on this area:

• PHP typically integrates into Apache as a DSO module (dynamic shared object).

• Now Apache is usually installed under Linux / Unix as a “pre-relaxed” model, that is, when it starts, a bunch of child processes are expanded (the exact number can be configured using Apache directives) and they are in the “process pool” ready to process requests.

• When the request arrives, the kernel scheduler selects the Apache process from the pool (if available), and the request is processed by the child.

• Based on the Apache configuration, if it detects that a PHP script needs to be executed, it passes it through the PHP DSO as the configuration in (1).

• Therefore, for each request, branching or slicing is not applied, which is effective. The entire request context is passed to the PHP level, which starts compiling and executing the PHP script.
  
  Note. The compilation step can be bypassed if the operation cache code is enabled, i.e. the first request for a PHP script is executed, and the associated operation codes are cached for reuse for subsequent requests (this is a global cache common to all child processes). Since the compilation step is expensive (parsing a script, etc.), for production systems it is best to use the operation cache code.

• When the PHP script completes, it goes into a cleanup procedure (built into PHP DSO), and it cleans up the memory for each request, closes all file descriptions, including db descriptors (based on how it opens). Some PHP methods have “persistent” descriptors (for example, opening db links, file descriptors) that can be stored in different requests, and therefore what function you use to open a particular resource (which corresponds to its corresponding documentation). By default, most resources are stored only for the entire duration of the PHP request, and they are destroyed after the completion of the PHP request.
  
  As far as dtors PHP objects are concerned, it all depends on the amount of object creation. Therefore, for global objects, its dtors will be called only at the end of the request cycle, while some of them will be called when they leave the scope when the function returns.
  
  Therefore, you get mgmt memory / resource for free. You can control it through unset () calls, immediately calling a free exemption. Also, starting with PHP 5.3, garbage collection can also be enabled at the request processing stage - see more details here: http://www.php.net/manual/en/features.gc.php

• Now this Apache child (which runs the PHP script) returns to the pool of processes ready to process the next request, as in step 3.

What I described above is typical of Apache / PHP on Linux / Unix environments, but I think something similar is true for Microsoft installations.

Also, with nginx and FastCGI + PHP, I think the same loop is true - that is, things are cleared at the end of the request loop that the PHP + FastCGI module processes. Here, too, when nginx starts, it starts a pool of individual processes processed by the FastCGI + PHP module, and the connection between nginx and FastCGI + PHP takes place in a unix socket.

Hope this helps.

Answer 2

This is not PHP, but a web server that processes requests. PHP does not work on its own. If the web page contains PHP code, such a request is delegated by PHP through the appropriate PHP SAPI module. There are multi-threaded multiprocessor web servers, and you can even imagine a single process web server, so it depends only on the web server if a separate thread or process is created for the request.

In many places in the PHP documentation, you may find lines like this on umask() :

Avoid using this feature in multi-threaded web servers. Better change the file permissions with chmod () after creating the file. Using umask () may lead to unexpected behavior of running the scripts and the web server itself at the same time, because they all use the same umask.

... how long does this thread remain alive? Does this thread support all static variables correctly? (e.g. database connection)

It sounds like a C ++ background. You probably mean global variables in PHP. PHP has built-in support for database connections, and you should not worry about such things. This is an implementation detail. Most SAPIs provide persistent database connections, but this is only for your curiosity. Persistent connections are created, one for each process that processes requests. Therefore, in this case, they are supported more by the process than by the thread.

When this thread is destroyed, does it call all destructors?

In PHP, destructors are called when a script completes execution. From the point of view of PHP developers, it doesn't matter where the script lives.