What are the differences between mod_php and cgi php script?
I mean, why it's better (is it?) to use mod_php instead simple php scripts, running them as CGIs?
Thanks
When using CGI : a PHP process is launched by Apache, and it is that PHP process that interprets PHP code -- not Apache itself.
In theory, a distinct PHP process has to be created for each request -- which makes things slower : Apache has more work to do to answer a request.
(Well, as pointed out by #AlReece45 in a comment, this can be made better using FastCGI)
When using PHP as an Apache module (mod_php, or mod_php5), the PHP interpreter is kind of "embedded" inside the Apache process : there is no external PHP process.
Which means :
No forking to answer a request (faster)
Better communication between Apache and PHP
Generally speaking, I would say that mod_php is the solution that's used the most.
Plain CGI requires process to be spawned for each request at the time of request.
mod_php requires you to use bloated apache instead of slick nginx or lighttpd. Besides, "better communication between Apache and PHP" mentioned by Pascal may harm apache (it harms anyone who develops in php!;-)).
FastCGI lets you separate php from the web server (possibly run it on the different host).
Also, php.net just released a vulnerability today where source code disclosure is possible if you are using mod_cgi to run PHP and your PHP version is older than PHP 5.3.12 or PHP 5.4.2.
http://www.php.net/archive/2012.php#id2012-05-03-1
Patch by upgrading or applying a mod_rewrite rule.
Related
I am downloading PHP for Windows. I got 2 options on the website.
PHP Thread Safe
PHP Non-Thread Safe
Please answer the following questions:
What is the difference between the two? What are the
advantages and disadvantages over one another?
I am developing an e-commerce website which will have heavy traffic, which one is more recommended and why?
From PHP documentation:
Thread Safety means that binary can work in a multithreaded webserver context, such as Apache 2 on Windows. Thread Safety works by creating a local storage copy in each thread, so that the data won't collide with another thread.
So what do I choose? If you choose to run PHP as a CGI binary, then you won't need thread safety, because the binary is invoked at each request. For multithreaded webservers, such as IIS5 and IIS6, you should use the threaded version of PHP.
So it really depends on the way that you want to use PHP:
Apache + LoadModule: Thread Safe
Apache + FastCGI: Non-Thread Safe
IIS: Thread Safe
IIS + FastCGI: Non-Thread Safe
PHP manual has nice installation instructions.
AFAIR running PHP with FastCGI is the preferable way, it performs faster and allows for more fine-grained security configuration.
Quick and simple: If you are using Apache edit your Apache24\conf\httpd.conf file and search for "loadmodule". If you see your loadmodule is referencing a .dll something like:
LoadModule php7_module "e:/x64Stack/PHP/php7.1.9/php7apache2_4.dll"
AddHandler application/x-httpd-php .php
PHPIniDir "e:/x64Stack/PHP/php7.1.9"
Then you want Thread Safety enabled or TS - Thread Safe version.
Else if you are using IIS or Apache with CGI then NTS flavor.
I use multiple stacks and within those multiple servers and versions of PHP so don't let the paths / php or server versions throw you.
In addition to Crack, since 5.4 you can use built-in web server (it works nice!).
Warning This web server was designed to aid application development.
It may also be useful for testing purposes or for application
demonstrations that are run in controlled environments. It is not
intended to be a full-featured web server. It should not be used on a
public network.
Is anyone using Magento with Apache worker MPM?
I've read conflicting reports of stability and security using worker instead of prefork, but have also read that worker is much faster than prefork.
PHP5 is thread-safe, but PHP extensions aren't all thread-safe. So it's considered harmfull to run a PHP application on a worker-mpm. And Magento is a PHP application like any other, chances are that you are using some PHP extensions somewhere (GD, Xml, etc) and that you can't test it for thread stability (really hard to test).
But what you can do is use apache as worker (really a lot more HTTP request handled, very useful for all static files), and push PHP out of Apache (so with no mod_php).
For that you will have to use PHP with fcgid or php-fpm, that is modern version of cgi to say it in a few words.
Is it possible that a code written for php server could be rewritten for apache server? Is it even a legal question in the first place? I have very little experience on server-side technologies.
THanks
You are comparing apples and oranges.
Apache is an HTTP server (well, a generic TCP/IP server with a strong focus on HTTP).
PHP is a programming language.
Software written in PHP can run on a variety of servers, so long as they support PHP. Apache can run software written in PHP via mod_php, mod_cgi, and a few other modules.
Apache can run software written in other programming languages.
Apache has the ability to serve PHP - read more at the wiki.
You do not have to rewrite anything. Php is a language which can be processed by Apache server.
Php is a language as is say ASP among others,
Apache is a web server as is say IIS among others
Apache and IIS can understand and process PHP coded sites.
You seem to discover the field, you should start by reading this kind of articles that will demistify the all the thing for you :
http://www.webdevelopersnotes.com/basics/client_server_architecture.php3
Good luck
Can anybody tell me why using the pcntl lib on production servers is discouraged? The PHP manual tells very briefly about it, and I'm in a dire need to use this library...
Is there another way to do the same thing in php?
pcntl is discouraged in production environments because the functionality it supports (fork, process control, signal handling) are fairly explicitly things you should not be using in a CGI style application. Now, if you're writing a daemon or command line application in PHP, that is another matter...
From the PHP manual:
Process Control should not be enabled within a web server environment and unexpected results may happen if any Process Control functions are used within a web server environment.
one has to be clear about the differences of a php cli script and a sapi/cgi script.
php on production systems may as well have support for pcntl.
the important thing here is to have 2 php config files. one for cli and one for cgi setup.
one then has to disable pctnl in the cgi setup because the real security issue is, that forking a script when executed by the webserver may leave zombie processes flooding the system.
in a cli environment it might be necessary to be able to write scripts that fork...
I have been trying to understand the exact meaning/purpose of loading php as an apache module vs the rest.
When php is installed as an apache module, what exactly happens? For example, does reading the php-ini file happen every time the php request comes or when the php module is loaded alone?
php.ini is read when the PHP module is loaded in both mod_php, FastCGI and FPM. In regular CGI mode, the config file have to be read at runtime because there's no preforked processes of any kind.
I think the only real advantage of running PHP as a module inside the web server is that the configuration might be easier. You get a lot better performance when you run it in FastCGI or FPM mode and can use a threaded or evented (instead of forked) Apache, or when you can throw out Apache altogether.
This link may help: http://2bits.com/articles/apache-fcgid-acceptable-performance-and-better-resource-utilization.html
Conclusion
If pure speed is what you are after, then stay with mod_php.
However, for better resource usage and efficiency, consider moving to
fcgid.
php.ini is read when the module is loaded in the case of an Apache module. PHP CGI uses a php interpreter executable like any other shell script would do. Since there is no state involved at each invocation, the config file would have to be read every single time in case of CGI.