On Mon, Aug 10, 2009 at 4:58 PM, Daevid Vincent <dae...@daevid.com> wrote:

> > From: Robert Cummings [mailto:rob...@interjinn.com]
> >
> > However, accelerators don't make scripts faster per se.
> > They merely cut out the script reading and parsing time.
> Which is a HUGE portion of time since PHP is a two-pass step. One that
> reads
> and compiles to opcodes (with syntax checking) and another which actually
> executes it.

obviously, this is sensitive to the amount of code being run in a single
request.  the more code, the more parsing / compile time.  but even that has
no bearing on how long the code of the script will run (as rob said).  if
youre dependent on remote resources, eg a database or other network
requests, like soap or rest to other remote servers, those are the sorts of
things that generally dominate the time spent handling a request.  even for
scripts run through the webserver, an opcode cache is a secondary
performance booster, where optimizing things like database performance will
usually drawf the returns a site gets from apc.  that being said, you
obviously want all the juice you can get, so running apc aside a tuned
database is ideal :)

> > So, while
> > you may experience 10% gain within the first second of your script
> > running, the use of an accelerator should have no bearing
> > down the road
> > except for the initial dynamic load of other scripts at runtime.
> This is sort of misleading.
> You will experience faster page loads if it's a web php file, and if APC
> does allow you to run cached scripts via CLI, then these scripts will start
> execution immediately too.

right, but from what ive seen the php environment is not persistent on the
cli like it is inside a webserver.  therefore, when the second request comes
in, apc will have to re-cache all of the scripts it cached the first time.
 afiak anyway.  if there is persistence in cli php, then how would one clear
out the cache for the cli based scripts??  apc gives you no tools to
accomplish this that im aware of, and theres no way you could do it from a
webserver either, since im pretty sure, cached scripts, just like apc 'user'
variables are only visible w/in a single domain (def correct me on that part
if im off base, i know eaccelerator handles things that way)

> > Long running scripts will see almost no benefit from an accelerator.
> PHP scripts are (like it or not) NOT designed to be daemons and run for
> long
> periods of time.

def not inside of the webserver, but on the cli i see no reason why php cant
be long running - and good at it.  you just have to like actually start
cleaning up old variables, lol.  so while its not as forgiving as the
webserver php environment, i doubt there are any real reasons to stay away
from a long running php cli app except performance vs. alternatives.

> The GC is no optimized for such things. It's quite
> inneficient from what I've read. The whole purpose of a PHP _page_ is to
> get
> in and get out. Hit it and quit it. Therefore memory efficiency is not as
> important as speed and ease of use.
> > This is the general reason why CLI acceleration isn't very useful. That
> said
> > though, one could certainly glean an advantage if they had a
> > cron job or other daemon that was loading a script often.
> As is probably often the case, moreso than a "long running script".
> I think a code optimizer is what would be desired if you're trying to make
> a
> faster script. However in this day and age, I suspect that the 2nd phase of
> the compiler already does all the optimizing it can before creating the
> byte
> code.

im guessing the optimization inside of apc is currently pretty weak, since
eacellerator has been the system most popular for optimization thus far, and
since apc is adding optimization as a future component of the project,
officially, which is still in alpha.



Reply via email to