PHP Run mode ____php

Original address:

Http://www.latrell.me/post-376.html

Overview

PHP running mode, is the implementation of PHP, a stand-alone executable (usually EXE program), one is embedded in the form of a module in the server program (usually DLL).

Technology

Implemented independently, the CGI (Common Gateway Interface, Universal gateways) technology is used, while the other is called an ISAPI in IIS (Internet Server application Programming Interface, Internet Server application Interface), Apache is called module (modules), more popular. Generally speaking, the execution of technology is called a pattern, and CGI is a technology and a pattern.

Iis:cgi/isapi
the difference of two methods of Apache:cgi/module

In CGI mode, when a request for a matching URL is received, the corresponding program is invoked 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 is independent of the server program, and when an error occurs, the server program is not affected, but consumes more resources.
Therefore, the CGI has better stability and security than the DLL, while the DLL has better execution efficiency and speed. FastCGI

FastCGI's introduction is to solve CGI performance problems, strictly speaking, fastcgi is also a CGI, it retains the stability of the CGI, combined with the advantages of the DLL.

The fastcgi is a language-independent, scalable, CGI-open extension that primarily acts to keep the CGI interpreter process in memory and thus achieve higher performance. As we all know, the repeated loading of CGI interpreters is the main reason for the low performance of CGI, and can provide good performance, scalability, fail-over characteristics, and so on if the CGI interpreter remains in memory and accepts the FASTCGI process Manager schedule.

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

From the above, the CGI is only going to implement a dynamic Web page, which is characterized by the process of fork a separate CGI program for each request, the benefit of which is to separate the Web server from the specific program, with a clear structure , Controllability is strong, at the same time the disadvantage is if in the case of high access requirements, the CGI process fork will become a very large server burden, imagine hundreds of concurrent requests cause the server fork hundreds of processes to understand. That's why CGI has been saddled with the stigma of low performance and high resource consumption.

The corresponding problem has a solution, the current popular scheme is the use of modular design, basically the current Web server has a corresponding module mechanism to expand its function, as long as the design of its specifications designed by the module, can be inserted into the Web server itself process processing, so performance has greatly improved, For example, IIS's Isapi,apache DSO. However, this approach is not without drawbacks, for example, for different Web servers, to be developed according to different standards, can not do webserver-free; for example, this will give input validation to the Web server, and cannot be handled freely; For example, once a problem occurs that affects the entire web Server processing processes, such as the insertion of a Web server process that cannot run as a multiple user, cannot process virtual host permissions, and so on.

Fortunately we have another choice, this is fastcgi. FastCGI is an extension of the CGI architecture, and his core idea is to build an intelligent, sustainable middle tier between the Web server and the specific CGI program, and run the CGI program so that the Web server simply submits the request to the layer, This layer then derives several reusable CGI program instances, the requests are then distributed to these instances, which are controllable, sustainable, reusable, so that the process is avoided repeatedly and fork, on the other hand, the operation of these instances can be monitored by the control and probing mechanism of the middle tier. Fork or recycling instances according to different conditions to achieve flexibility and stability.

Someone has done testing, using CGI to run PHP is the least efficient, mod_php way performance is very good, almost 50 times times the CGI method, 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 multithreaded CGI interpreter.

This may be a multifaceted consideration, for example:

1, you can not, in any case, stable use of multithreaded CGI interpreter on Windows platform, whether it is IIS ISAPI method or Apache module method, they always run for a period of time to crash. Strange. But it does exist.
Of course, there are many times when you can stabilize the use of multithreaded CGI interpreter, but you may find that the Web page sometimes error, in any case can not find the reason, and the fastcgi way to change the probability of this error will be greatly reduced. I'm not sure why, but I think the CGI interpreter for the standalone address space may eventually be a little bit more stable than the form of the shared address space.

2, performance. Performance. Is it possible that fastcgi is faster than a multithreaded CGI interpreter. But sometimes this is true, only testing your site, can be final conclusion. Why, I find it difficult to say, but there is information that in the era of Zend Winenabler, Zend is also recommended to use the Windows platform fastcgi instead of IIS ISAPI or Apache Module, but now Zend does 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 of memory per process, and multiplies this number by 50 or 100 to try.

2, performance. It's true that sometimes the multithreaded CGI interpreter is faster, huh, and sometimes it's stable.