El 28/10/12 14:52, Rasmus Lerdorf escribió: > On 10/28/2012 04:54 AM, Terry Ellison wrote: > >> From the perspective of a production sysadmin, I've always just set >> apc.stat=0 but then cleared the cache following any change. This gives >> the best of both worlds: the performance dividend of no stat'ing and >> avoiding the weird gremlins that sometimes occurred if I didn't flush >> the cache. The one-off hit for repriming the cache again is pretty >> small and the "release from dev to live" cycle isn't a common event. >> For a multi-app configuration, it would be a very simple matter to write >> an admin script which clears the cache based on some REGEX filename >> match, so that this could be integrated into application release scripts. > This causes deploy race conditions though. You want requests that are > already in progress right when the deploy happens to continue executing > with all the old versions of the scripts. The PHP realpath cache helps > here. If you clear out the opcode cache on the deploy you end up with > these requests all picking up the new version mid-request. > > -Rasmus Don't you already have the same race condition for requests in progress when atomically replacing the docroot?
IMHO it would be appropiate for APC to delay the cache flush until all running requests have finished (and obviously not starting any new one with the old cache). At least unless explicitely overriden. Perhaps this behavior is unwanted in some scenario with a long running process which dynamically loads new files, but certainly is not what is expected in the common case. If you instead perform a graceful restart of apache, I think that would reset the APC cache, and the apache itself makes the new requests isolated from the old ones. -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
