Sorry forgot to mention that we used APC with apc.stat turned off
which will give a little bit more performance gain, but it does mean
flushing the cache on every code push (which is trivial).


On Fri, Jan 8, 2010 at 11:30 AM, J Ravi Menon <> wrote:
> Hi,
> A note on bytecode caching and include/include_once performance. A
> while ago when we were profiling our code, we did notice that file
> includes do take a noticeable percentage of overall overhead (enough
> for us to look into it more deep). We are using apc cache on a
> standard LAMP platform (linux 2.6 series, apache 2.2x and PHP 5
> series).
> Our includes were using 'relative' paths (e.g.  include_once
> '../common/' or include_once 'lib/' ) and
> within APC cache logic, it resolves such relative paths to absolute
> paths via a realpath() calls. This can be fairly file-system intensive
> (lots of syscalls like stat() and readlink() to resolve symlinks
> etc...). APC uses absolute paths as key into the opcode cache.
> This gets worse if it has to find your files via the 'ini_path'
> setting (and most of your library or common code is not in the first
> component or so ).
> So from APC cache perspective, it is most efficient if your include
> paths are all absolute (realpath() logic is skipped) - e.g.:
> include_once $BASE_DIR . '/common/';
> include_once $BASE_DIR . '/lib/';
> and so on where '$BASE_DIR' could be set via apache Setenv directives
> ( $_SERVER['BASE_DIR'] or even hardcoded all over the place).
> There were other issues with include vs include_once and apc cache,
> but I don't recall why there were performance difference (with include
> only even with relative paths, the performance was better, but
> managing dependencies is to cumbersome).
> Not sure how other bytecode cache handles relative paths but I suspect
> it has to do something similar.
> From a pure code readability point of view and more automated
> dependency management (as close to compiled languages as possible), I
> do favor include_once/require_once strategy with absolute path
> strategy, but it is not unheard of where to squeeze out maximal
> performance, a giant single 'include' is done. Sometimes this is done
> on prod. systems where a parser goes through and generates this big
> include file, and ensure it is placed somewhere in the beginning the
> main 'controller.php' (MVC model) and all other includes stripped off.
> Hope this helps in making your decision.
> Ravi
> On Fri, Jan 8, 2010 at 8:59 AM, Robert Cummings <> wrote:
>> wrote:
>>> On Thu, 07 Jan 2010 22:48:59 -0500, (Robert Cummings)
>>> wrote:
>>>> wrote:
>>>>> Thank you all for your comments. I did not know about bytecode caches.
>>>>> They're an
>>>>> interesting concept, but if I am interpreting the paper
>>>>> correctly
>>>>> they only double
>>>>> the average speed of operation, which is rather less than I would have
>>>>> anticipated.
>>>> I strongly advise that you take the time to try a bytecode cache. Within
>>>> linux environments I am partial to eaccelerator. In IIS environments I now
>>>> use WinCache from Microsoft. From my own observations with a multitude of
>>>> different types of PHP web applications I find that the speed gain is 
>>>> closer
>>>> to 5 times faster on average.
>>> Five times faster is certainly more attractive than twice as fast. But
>>> under what
>>> circumstances is this achieved? Unfortunately these days it is difficult
>>> to find any solid
>>> information on how things actually work, but my impression is that caches
>>> only work for
>>> pages which are frequently accessed. If this is correct, and (as I
>>> suspect) somebody looks
>>> at my website once an hour, the page will not be in the cache, so it won't
>>> help. Also one
>>> of the more popular parts of this website is my photo album, and for this
>>> much of the
>>> access time will be the download time of the photos. Furthermore as each
>>> visitor will look
>>> at a different set of photos, even with heavy access it is unlikely that
>>> any given photo
>>> would be in a cache.
>> A particular cache of bytecode is usually pushed out of memory when the
>> configured maximum amount of memory for the bytecode cache is about to be
>> exceeded. Additionally, the particular cache that gets eliminated is usually
>> the oldest or least used cache. Given this, and your purported usage
>> patterns, your pages will most likely remain in the cache until such time as
>> you update the code or restart the webserver.
>>> Despite these comments the access times for my websites seem to be pretty
>>> good --
>>> certainly a lot better than many commercial websites -- but have a look at
>>>, and see what you think. (I am in the process of
>>> updating this,
>>> and know that the technical notes are not currently working, but there is
>>> plenty there to
>>> show you what I'm trying to do.)
>> I'm not disputing your good enough statistics. I'm merely asserting that a
>> bytecode cache will resolve your concerns about file access times when your
>> code is strewn across many compartmentalized files. In addition, I am
>> advising that it is good practice to always install a bytecode cache. One of
>> the first things I do when setting up a new system is to ensure I put an
>> accelerator in place. Once it's in place, no matter how many pages or sub
>> sites I put up, the accelerator is already in place and providing benefits.
>> Cheers,
>> Rob.
>> --
>> Application and Templating Framework for PHP
>> --
>> PHP General Mailing List (
>> To unsubscribe, visit:

PHP General Mailing List (
To unsubscribe, visit:

Reply via email to