On Mon, Aug 10, 2009 at 4:58 PM, Daevid Vincent <daevid@xxxxxxxxxx> wrote: > > From: Robert Cummings [mailto:robert@xxxxxxxxxxxxx] > > > > 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. http://pecl.php.net/package-info.php?package=optimizer&version=0.1alpha1 -nathan
