On Fri, Feb 22, 2008 at 8:25 AM, Jochem Maas <jochem@xxxxxxxxxxxxx> wrote: > Nathan Nobbe schreef: > > On Thu, Feb 21, 2008 at 12:01 PM, Jochem Maas <jochem@xxxxxxxxxxxxx> > wrote: > > > >> Richard Lynch schreef: > >>> If it's that inter-tangled, then I would hazard a WILD GUESS that the > >>> __autoload will still end up loading everything... > >> but not on every request ;-) ... I do use output caching, and I know > >> not everything is actually used in every request. > > > > > > i think youre good to go w/ autoload not loading everything up, but what > > about existing include / require directives? if the code doesnt already > > use __autoload() its almost certainly strewn w/ these. so i think if > you > > want the boost from __autoload, not loading up everything, youll at > least > > have > > to strip these out. > > I know, I have ... I wrote the code in the first :-) > > > > > I know - but it's a rubbish solution because it offer no control as to > what > >> is cleared from the APC cache, sometimes I want to clear opcodes, > >> sometimes user-data, > >> sometimes both ... graceful means being forced to clear everything. > > > > > > you can pass a parameter to apc_clear_cache() > > http://www.php.net/manual/en/function.apc-clear-cache.php > > that distinguishes what you want to clear; user data or cached opcode. > > obviously calling it from the cli will not clear the webserver user > cache > > though. > > I know apc_clear_cache() ... the whole problem is doing it on multiple > servers. > your statement about not being able to do it from the CLI (which I know) > is half > correct AFAICT - you can't clear anything cached in APC via mod_php from > the > CLI ... which is my whole problem in a nutshell :-) > > > > > One would think that there was something like this indeed - I cannot > find > >> it, > >> but then there must be something ... I assume, for instance, that > Yahoo!** > >> occassionally > >> see fit to clear APC caches on more than one machine and I doubt Rasmus > >> sits there and > >> opens a browser to run apc.php on each one ;-) > > > > > > i dont know how yahoo does it, but i do know a little about how facebook > > does it; they had > > 3 speakers at the dc php conference last year. i think you might find > these > > slides helpful, > > (sorry for the ridiculuus url) > > > http://www.google.com/url?sa=t&ct=res&cd=1&url=http%3A%2F%2Ftekrat.com%2Ftalks_files%2Fphpdc2007%2Fapc%40facebook.pdf&ei=tce9R9T4FqrszATeiZG6CA&usg=AFQjCNF_1Ecm2cL1EINgRQG9k3fTEclzpA&sig2=ifrJK545M2liBdXbRrHrIw > > thanks for that link - it gives me a few angles and ideas to work on! > > > you can use capistrano to deploy the new files; but it may be more > > convenient to use php > > and http requests to update all the server caches; *just a thought*. > > I'm not using capistrano for file deployment (files are stored centrally > on a GFS volume to which all servers have access) ... I am (will be) using > capistrano in order to run commands symultaneously on all webservers ... > one of which will have to be some kind of cache control mechanism, which > is > the case of apc will probably be a php script that hits apc.php on the > local > machines webserver (but I want to be able to run said php script on > multiple machines at once, or at least without having to log in to every > machine ... and I see no reason to duplicate the functionality of > capistrano, > I just write a php script to do the actual apc.php interaction on the > local webserver that cap can call on each machine. > > > there are optimizations that are possible as well, such as setting, > > apc.stat=0 and > > got that one set already. :-) > > > using apc_compile_file() rather than clearing the entire cache, but > these > > techniques add > > I read the facebook story about preloading the cache (using memory > dumping/loading) > in combination with apc_compile_file() ... which is cool but a little too > much > effort given the time/budget I have to complete this (my client doesn't > have > X billion to burn ... but funnily enough they do have a viable business > model ... > but that's another story ;-) > > > complexity. it sounds like you just want to get a decent bumb w/o too > much > > additional > > complexity, so i wouldnt recommend them here, but i thought id mention > them > > in passing.. > > apart from writing some kind of management cli script to [remote] control > the > apc cache of each webserver I'm also going [to have to] incorporate > memcache > functionality into my current caching stuff - many thanks for that PDF > link > (I hadn't come accross it before in my searching, although I had > discovered > various other facebook+apc/memcache/caching related presentations) it's > given me > jsut enough code and ideas to hang myself with ... er I mean write a > transparent > memcache layer into my app :-) i assumed you had something pretty solid in place already; tossed the link out there, cause its about the only practical thing i know of (personally). it also sounds like youve got your hands on some projects a little bigger than mine; but just today, it looks like i might have my ticket into the big leagues; so hopefully sometime soon i wont be talking out my ass as much about what works in practice on large php apps. dont hold your breath though :O -nathan
