On Wed, December 12, 2007 1:33 pm, Ravi Menon wrote:
> We have long running daemons written in php ( cli, non-apache
> contexts) with the typical pattern:
>
> while( !$shutdown )
> {
> $c = new SomeClass;
>
> $c->process();
> }
>
> For performance reasons, would it help if apc.enable_cli is turned on:
>
> apc.enable_cli integer
>
> Mostly for testing and debugging. Setting this enables APC for the
> CLI version of PHP. Normally you wouldn't want to create, populate and
> tear down the APC cache on every CLI request, but for various test
> scenarios it is handy to be able to enable APC for the CLI version of
> APC easily.
>
>
> I am slightly confused by the statement - 'Mostly for testing and
> debugging.....' .
>
> On each loop iteration, does php recompile the code in 'SomeClass' (
> and all its dependencies ) or it is really cached ( as it has seen the
> class code once ).
>
> If there is a php internals document on such issues, do let me know.
The following is almost-for-sure correct, but I wouldn't swear in
court...
Step 0. Read PHP/HTML source code.
Step 1. PHP uses a 2-pass compiler and generates byte-code.
Step 2. The byte-code is then feed to the executer.
Step 3. Executer spews output (or crashes or whatever)
APC and other caches add a Step 1A., which stores the byte-code in RAM
under the filename (or full path, depending on config) as a key.
Therefore, adding APC will not affect in any way the "while" loop --
It's compiled once in Step 1, and that's it.
If you re-run the same script again and again, however, APC in CLI
might be able to keep the script around and avoid a hit to the disk to
LOAD the script (Step 0 above) as well as avoiding the 2-pass
compilation to byte-code (Step 1 above).
NOTE:
Step 0 is the REALLY expensive step where APC et al are REALLY
boosting performance.
APC et al *could* just insert step 0A and store the PHP source, and
have ALMOST the same benefits.
However, storing the compiled version at Step 1A gets you some free
gravy in not re-compiling the PHP source to byte-code, so they do that
because, well, it's essentially FREE and saves a few more cpu cycles.
But the REAL boost, again, is from not hammering the hard drive (slow)
to load PHP source into RAM, Step 0.
PS
If you are really concerned about the constructor of SomeClass being
expensive, time it and see.
YOU may be doing something incredibly expensive there like
re-connecting to the database (slow!) each time.
You may also not even NEED a whole new SomeClass every time -- Perhaps
you could just make a singleton and then reset its values and call
process() with the new values instead of building up a whole new
instance each time.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/from/lynch
Yeah, I get a buck. So?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
