PHP run mode

PHP run mode

PHP run mode, is the way PHP executes, one is a separate executable program (usually EXE program), one is embedded in the form of a module in the server program run (usually DLL program).

Independent execution, using CGI (Common Gateway Interface, Universal Gateway Interface) technology, while the other is called ISAPI in IIS (Internet S erver Application Programming Interface, Internet Server application Interface), Apache is called Module (modules), a little more popular. In general, the implementation of technology is called pattern, CGI is a technology is also a pattern.

Iis:cgi/isapi
Apache:cgi/module

The difference between the two methods

In CGI mode, when a request for a matching URL is received, the corresponding program is called and the data sent by the client is entered as input;
In a modular (DLL), PHP is started and run with the Web server;
In CGI, the execution program and the server program are independent, the server program will not be affected when the execution program errors, but will consume more resources.
Therefore, CGI has better stability and security than DLLs, while DLLs have better execution efficiency and speed.

Benefits of FastCGI
1) can support the interpreter of different versions of the same script on one system, such as PHP4, PHP5
2) As long as you install an Apache module, you can support PHP, Python, Perl, etc., there is no need for them to install their own module
3) Get better access control, more secure than PHP running in safe mode, foreign large virtual host vendors such as Dreamhost,bluehost, GoDaddy, etc. are used
FastCGI

FastCGI's introduction is to solve the CGI performance problem, strictly speaking, fastcgi is also a CGI, it preserves the stability of the CGI, while combining the advantages of the DLL.

FastCGI is a language-independent, extensible architecture for CGI open extensions whose main behavior is to keep the CGI interpreter process in memory and thus achieve high performance. As we all know, the repeated loading of CGI interpreter is the main reason of poor CGI performance, if the CGI interpreter remains in memory and accepts the FASTCGI process manager scheduling, it can provide good performance, scalability, fail-over characteristics and so on.

The workflow of the common CGI:
The Web server receives the user request and submits the request to the CGI program, and the CGI program processes the requested parameters, then outputs the standard HTML statement back to the Web Server,web server and returns it to the client, which is how the common CGI works.

From the above, CGI is only a Dynamic Web page, this process is characterized by each request, the Web server fork out a separate CGI program process to handle, the advantage is that the Web server and the specific program processing independent, Structure clear , Controllability is strong, at the same time the disadvantage is that if in the case of high access requirements, CGI process fork will become a very large server burden, imagine that hundreds of concurrent requests caused the server fork out hundreds of processes on the understanding. This is why CGI has been saddled with poor performance and high resource consumption for notoriety reasons.

The corresponding problem has a solution, the current popular solution is the use of modular design, basically the current Web server has a corresponding module mechanism to expand its functionality, as long as the design of the module designed by the code can be inserted into the Web server itself process processing, so performance has greatly improved, For example, the Isapi,apache DSO for IIS. However, this method is not without shortcomings, for example, for different Web servers, to be developed according to different standards, can not do webserver independence; For example, this will be the input validation of the work to the Web server, there is no way to handle it, for example, if the problem will affect the entire web The server processing process, such as the insertion of a Web server process, cannot run with multi-user marks, cannot handle virtual host permissions, and so on.

Fortunately we have another option, this is fastcgi. FASTCGI is a CGI-based extension, and his core idea is to build an intelligent, sustainable middle tier between Web server and specific CGI programs that governs the operation of CGI programs so that Web server simply submits the request to this layer. This layer then derives several reusable CGI program instances, and then distributes the requests to these instances, which are controllable, sustainable, reusable, so that the process is not repeatedly fork, on the other hand can be monitored through the middle layer control and detection mechanism to monitor the operation of these instances, According to different conditions fork or recycling examples, to achieve flexibility and stability for both purposes.

Some have been tested, using CGI to run PHP is the worst, mod_php way performance is very good, almost 50 times times the CGI mode, but can not guarantee the virtual host site security isolation, and fastcgi performance is basically and mod_php equivalent, This is also the result of using the suexec to switch the virtual host site to run the user.

Why use fastcgi instead of a multithreaded CGI interpreter?

This may be due to a variety of considerations, such as:

1, you can no matter how stable on the Windows platform using multithreaded CGI interpreter, either IIS ISAPI mode or Apache module mode, they always run for a period of time crashed. Strange, huh? But there is such a situation!
Of course, there are a lot of times you can use the multi-threaded CGI interpreter, however, you may find that the Web page sometimes error, no matter how to find the reason, and in the fastcgi way when the probability of this error will be greatly reduced. I don't know why, I think the CGI interpreter for the standalone address space may eventually be a little bit more stable than the shared address space.

2, Performance! Performance? Is it possible that fastcgi is faster than a multithreaded CGI interpreter? But sometimes it is, only test your site, to conclude. Why, I find it difficult to say, but there is information in the Zend Winenabler era, Zend is also recommended to use the Windows platform under the fastcgi rather than the IIS ISAPI or Apache Module, but now Zend do not do this product.

Reasons not to use fastcgi

1, multi-process consumes more server memory than multithreading, the Php-cgi.exe interpreter consumes 7 to 25 megabytes per process, and multiplies this number by 50 or 100 to try.

2, performance. It's true that sometimes multithreaded CGI interpreters are faster, hehe, and sometimes it's stable.

Compared to the traditional CGI mode,

The advantage of mod_php is to use multithreaded mode to respond to requests, and after each execution, the thread disappears and all resources disappear. The problem is that one of the threads could kill the main process, causing the server to go down. And a large number of logical computations will affect the corresponding speed of the main process;

The advantage of the fastcgi is that the primary server process communicates with the CGI manager through the socket, and the CGI manager arranges one of the CGI processes from the CGI process pool, which recycles the resources but does not exit and waits for the next processing. This will not affect the server process at all, even if the CGI process crashes. And the server calculation is more simple, only responsible for sending and receiving data. is equivalent to a load balancing solution that can support a large number of accesses. But I think the problem is because the CGI process will not exit, there may be some stability problems, such as incomplete recovery, it will cause the crash, so although the main server process is not hanging, but when processing a person's calculation, may be in response to this request hangs, so stability is not completely reliable.

Reference: http://www.v2ex.com/t/160602

PHP run mode