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
