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). Ravi On Fri, Jan 8, 2010 at 11:30 AM, J Ravi Menon <jravimenon@xxxxxxxxx> 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/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
