APC works by storing the opcodes from PHP files in shared memory. When PHP is used with a web server (eg Apache) then the shared memory has a long life. When called from the commandline, then the APC cache is created and destroyed for each process. APC is disabled on the commadnline by default, probably due to this.
I have a theory that there will be benefits from using APC if a PHP process is forked (with pcntl_fork()
as presumably the same opcode cache can be used. This may only apply to files included after the fork.
What's the best way to benchmark this? Can anyone either test this or explain whether the theory is correct or not?
<?php
if (pcntl_fork()) {
// parent
include 'huge-file.php';
} else {
// child
sleep(1); // stop race condition
include 'huge-file.php'; // will this use APC's cache?
}
APC has an impact in CLI mode in two cases:
- The same file is included repeatedly, either by the same script (e.g. a file containing some data cache), or by multiple processes
- You use apc_fetch() (always returns false if apc is disabled)
Note that APC disables itself in CLI by default; you have to enable it with apc.enable_cli=1
.
Here is a quick benchmark:
<?php
for ($i = 0; $i < 1000; ++$i) {
// cache.php contains the output of 'var_export(get_defined_constants(true))'
require 'cache.php';
}
Result without apc:
$ time php test.php
real 0m1.219s
user 0m1.208s
sys 0m0.008s
Result with apc:
$ time php -dapc.enable_cli=1 test.php
real 0m0.252s
user 0m0.244s
sys 0m0.004s
In this case, APC does have a significant impact on performance.
With pcntl_fork(), APC should have exactly the same impact than running multiple PHP scripts under apache's mod_php or php-fpm: if multiple children scripts include the same files, the included files will be parsed only once.
In PHP 5.5, the bundled opcache extension replacing APC also optimizes the code, so it should not only impact require
performance, but also the performance of the code itself.