NYCPHP Meetup

[Hans Zaunere]

Some tips from Rasmus on PHP General on performance...


---
Hans Zaunere / President / New York PHP
   www.nyphp.org  /  www.nyphp.com



Rasmus Lerdorf wrote on Friday, March 03, 2006 11:51 PM:
> 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