Re: [PHP] Re: MMcache question
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
Re: [PHP] Re: MMcache question
you sound exactly like someone i know.. i enjoy reading your long posts.. no sarcasm ;-) i'd defently hire you, but you're probably too expensive ;-) Richard Lynch wrote: 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. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: MMcache question
On Thu, June 30, 2005 5:25 pm, Sebastian said: you sound exactly like someone i know.. i enjoy reading your long posts.. no sarcasm ;-) i'd defently hire you, but you're probably too expensive ;-) Thanks! Some people take my posts far more seriously and/or negatively than I intend, though... [shrug] That's the 'net for ya. Believe it or not, I pre-censor a whole lotta stuff before I hit Send even if it don't seem like it. All caught up with PHP-General. Whoo Hooo! -- 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
[PHP] Re: MMcache question
The use of mmcache (try eaccelerator btw!) is not visible without some stress on the server. Try building a rahter complex PHP script, which does some crazy iterations but without DB connections and such things which are not related to PHPs abilities and use ab (apache benchmark tool) to issue many simultaneous requests to that page; do it a few times, with mmcache and without mmcache enabled and will surely see the differences. 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. On heavy loaded sites and on sites that use lots of libraries and objects mmcache (eaccelerator) does a perfect job. Catalin Merlin wrote: Hi there, I just steped over mmcache: http://turck-mmcache.sourceforge.net/index_old.html#install After installing it, I can not see a real performance gain at all. The system is installed corectly and mmcache.php tells me it is active and running. Now I saw that there is a mmcache API. Does that mean that I do have to recode my whole app to make use of mmcache?! Thanx for any hint, Merlin -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
