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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
