Re: Re: APC and PHP 5.1.2

Jens Kleikamp wrote:

steve wrote:

Thanks for that! It meant that I should look in other directions which helped me figure out the problem. Can you try again with: apc.optimization=1

Your script also seems to work on my sytem with optimization=1.

The optimizer doesn't work very well at this point. It will get some attention soon I hope. If you need to squeeze every bit of performance out of your code there are usually much bigger wins than an optimizer will give you in going through and cleaning things up. The easy list of low-hanging optimization fruit are: 1. Check your include_path and your includes. If you make heavy use of files in a directory on your include_path, make sure that path is first. And yes, that means before "." as well. In fact I wouldn't even put "." in your include_path, just use

      include './file.php';

if you want to include from the current directory or relative to the current directory. You are going to save quite a few stat calls by cleaning this up. 2. Minimize your use of include_once/require_once. If you can clean up your dependencies and your include tree such that there is no question of double-inclusion anywhere everything will be much happier. A redundant include is obviously going to waste useless cycles, but even if you don't hit the redundant case, the _once operations are optimized for the non-cached scenario and actually calls open() on every file which makes sense without an opcode cache because you are going to need the file opened, but with a cache you are going to get the opcodes from the cache and this becomes a useless extra open() syscall. 3. Try to avoid pushing things out of the compiler and into the executor. That's a bit cryptic, but it basically means try to avoid dynamically defining functions and classes.

    Good:  <?php  class foo { ... } ?>

    Bad:   <?php
                 if($some_condition) {
                   class foo { ... }
                 }
           ?>

In the second case the foo class has to be defined at script runtime which is much slower than if it is unconditionally defined in the compiler. Without an opcode cache this isn't much of an issue, of course since you have to run both stages, but with an opcode cache where you skip the compile phase and just feed the opcodes straight to the executor, the more you can handle when you compile the opcodes the faster your script will run because the executor has less work to do. 4. Make use of APC's apc_store/apc_fetch mechanism. If you have any sort of large array of data you need often, stick it in shared memory with an apc_store() call. For example, a typical thing you see in PHP applications is some sort of config.php file. It might look like this:

    <?php
       $config['db_type'] = 'mysql';
       $config['db_user'] = 'bob';
       $config['db_pswd'] = 'foobar';
       $config['data_dir'] = '/var/www/app_data';
       ...
    ?>

And then on every page you have: include './config.php'; This is very inefficient even though the actual file will be cached in the opcode cache, it still has to execute and create the array. You can cache the created array like this:

    if(!$config = apc_fetch('config')) {
       include './config.php';
       apc_store('config',$config);
    }

Here we only include the config file and thus create the $config array if it isn't in the cache. So this will only happen on the very first request. From then on it will get pulled from the shared memory cache. If you look around there are usually a couple of candidates for this sort of caching in every application and it can make quite a difference for large arrays. Try to avoid caching objects because they need to be serialized and unserialized in and out of the cache and you can only cache the properties anyway, so pull the data you want to cache into an array and cache that. -Rasmus