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.
Related
In the documentation it says "mostly used for debugging" which would lead me think "never enable it unless you've a problem and need to do some debugging," however reading mostly everything that I could find about it says to enable it "opcache.enable_cli 1" but why? I could not find any information concerning this matter, so if anybody knows, why should I enable it if the documentation basically says to keep it on 0?
With PHP7 and file-based caching, it can now make sense to enable opcache for CLI. The best possibility would be to have a separate php.ini for CLI with the following configuration:
opcache.enable=1
opcache.enable_cli=1
opcache.file_cache="/tmp/php-file-cache"
opcache.file_cache_only=1
opcache.file_cache_consistency_checks=1
opcache.file_cache_only=1 makes sure that the in-memory opcache is disabled and only files are used, which is what you want for CLI. This should boost execution time by quite a bit.
In the php.ini for FPM, you will want to have the same settings but use opcache.file_cache_only=0, so in-memory opcache is used and the file cache is used as a fallback (which also makes FPM faster, because the file cache reduces warmup time when FPM is restarted or opcache is reset, because the cached files remain).
This way, CLI and FPM share the file cache, and FPM has the in-memory cache as a second primary cache for maximum speed. A great improvement in PHP7! Just make sure to choose a directory for opcache.file_cache that both CLI and FPM can write to, and that the same user does the writing/reading.
UPDATE 2017
I would not recommend to use the file cache with FPM anymore (only use it for CLI), because there is no way to reset the cache when setting opcache.validate_timestamps=0 - the file cache prevents PHP-FPM from recognizing any changes, because opcache_reset() or even a complete PHP-FPM restart does not affect the file cache and there is no equivalent for the file cache, so changed scripts are never noticed. I reported this as a "bug"/"feature request" in March 2016, but this is currently not seen as an issue. Just beware if you use opcache.validate_timestamps=0!
Leave it off. It's primarily there for use while debugging issues with OPcache itself.
The opcache.enable_cli option enables PHP OPcache when running PHP scripts from the command line (using the php command). However, keep in mind that for PHP 5.x the OPcache extension works by storing cached opcodes in the memory of the current process. This is only useful when the process that's running PHP is going to be handling multiple requests that can reuse these opcodes, like in a web server or under FastCGI. For a process like the PHP CLI, which runs one "request" and exits, it just wastes memory and time.
As per PHP docs:
opcache.enable_cli boolean enables the opcode cache for the CLI version of PHP. This is mostly useful for testing and debugging.
Therefore it should be disabled unless you're really need this.
This can be useful when you've some long-term migration process running from the command-line (personally I've tested OPcache v7.0.3 for CLI by running some extensive migration script and I didn't see much performance improvements).
How can I tell if PHP is running in FCGI mode ?
phpinfo , sapi_name() returns always CGI/FCGI even when running in suPHP mode.
Is it possible to produce a php code that fails/work only with FCGI?
I know it is possible to force suPHP to fail when the script is owned by root, I am looking for the same kind of trick.
EDIT: found "PHP_FCGI_CHILDREN" in environnement only when i think fcgi is enabled , maybe that is it ?
suPHP runs PHP in CGI mode as a separate process, which is why you see CGI/FCGI.
When you run PHP in FastCGI mode, you can set particular environment variables, such as (what you mentioned) PHP_FCGI_CHILDREN. This could be a way, but you could also modify the FastCGI wrapper script to define your own custom environment variable and test on that.
If i make changes in php-ini:
when does php react?
is it possible, that I get other data in phpinfo()
than php realy uses?
If you are using PHP as an Apache module, you will have to restart the httpd service to have PHP re-read php.ini, or changes will not be taken into account.
From this PHP manual entry.
The configuration file (php.ini) is read when PHP starts up. For the server module versions of PHP, this happens only once when the web server is started. For the CGI and CLI versions, it happens on every invocation.
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.
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.