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/somefile.inc' or include_once 'lib/somefuncs.inc' ) 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/somefile.inc'; include_once $BASE_DIR . '/lib/somefuncs.inc'; 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 <robert@xxxxxxxxxxxxx> wrote: > clancy_1@xxxxxxxxxxxx wrote: >> >> On Thu, 07 Jan 2010 22:48:59 -0500, robert@xxxxxxxxxxxxx (Robert Cummings) >> wrote: >> >>> clancy_1@xxxxxxxxxxxx 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 >>>> http://itst.net/654-php-on-fire-three-opcode-caches-compared 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 >> http://www.corybas.com/, 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. > -- > http://www.interjinn.com > Application and Templating Framework for PHP > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
