On Sat, June 25, 2005 3:37 am, Catalin Trifu said: > No! You don't have to rewrite your application. What mmacache does is > to keep a "bytecode" version of the script available so that PHP won't > have > to reparse the script every time, which is expensive and also has a nice > code optimizer. This is a common misconception about PHP cache systems... The PHP parser is *NOT* the "big win" Avoiding the hard disk read is the "big win" The PHP parser, even in PHP 5, just is NOT that complex. We're not talking C++ here. We're not even talking C. It's PHP! The entire language fits on a couple web pages for cripes' sake. [Not all the module/function stuff, just what the PARSER has to figure out] mmcache, Turck, eaccalerator, Zend Cache, whatever. They all have this oft-repeated misconception that they make your script faster because the PHP parser is taken out of the loop. The PHP parser being taken out of the loop is just gravy -- Something the cache does just because it's mind-numbingly easy, once you develop a cache at all. The true performance win is not having to hit the hard drive to *read* the PHP script before you parse it. It's already in RAM. The Zend Cache will make most applications at least 2 X as fast. About 1.9 of this speed increase probably comes from the fact that the script is in RAM. And maybe only 0.1 from the PHP parser getting bypassed. I made the 1.9 and 0.1 numbers up out of thin air for illustrative purposes!!! They are NOT real numbers. They *ARE* representative of the imbalance at work here. The 2 X number ain't made up. That's what Zend customers routinely reported in worst-case situations when I worked there (several years ago). 4 X was often the real world speed-up. You don't get a 2 X speed-up from the PHP parser not ripping through a bunch of text. No way. No how. You could (possibly) achieve similar speed-ups just having a RAM disk for all your PHP code. Though I think even a RAM disk has significant overhead in mimicing the file control function calls that is beggared by the Cache lookup. There are pathalogical cases where the Cache will do you no good at all, or even degrade performance. The most obvious one is if you have *WAY* too many PHP scripts scattered into *WAY* too many files, and your site has a *LOT* of pages with widely-distributed viewing. IE, imagine a site with 10,000 pages, but instead of the home page being the one everybody hits all the time, that site has everybody deep-linking to all the pages equally often. Also imagine that each of the 10,000 pages opens up 10 *different* PHP include files to generate its output. [This is an extreme pathalogical example... But less extreme real-world cases exist.] The Cache will end up thrashing and re-loading script after script because they can't all fit in RAM at once. I saw one client that literally had snippets of PHP code spread out in thousands of files, which they were combining to create PHP scripts "on the fly" from the database in a combinatorial-explosive algorithm. The Cache they used (not naming names, because it's irrelevent) was actually slowing down their site, a little bit, due to the overhead involved. They would have to have consolidated scripts, thrown *WAY* more RAM at it, or just completely changed their algorithm to fix it. I think they ended up doing a little of all that. Plus throwing more hardware at it. PHP is a shared-nothing architecture for a reason. :-) Most sites have a couple include files that get loaded on every page. Those pretty much get loaded into RAM and never move. And that's where the cache shines. No disk read. Just RAM. Raw Hardware Speed, baby. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
