On Sat, May 11, 2013 at 6:30 PM, Joe Watkins <krak...@php.net> wrote:
> On 05/11/2013 11:10 AM, Joe Watkins wrote: > >> On 05/10/2013 08:54 PM, Christopher Jones wrote: >> >>> >>> >>> On 05/09/2013 05:02 AM, Pierre Schmitz wrote: >>> >>>> Hi, >>>> >>>> I am testing PHP 5.5 atm and how we can package it for Arch Linux and >>>> provide an upgrade path for users. The RC1 looks pretty solid so far. >>>> >>>> As the new opcache does not provide a user cache to store custom >>>> variables, I would be glad if you could clarify what the best migration >>>> from 5.4 would be. >>>> * Is APC basically dead and wont support PHP 5.5? >>>> >>> >>> From the lack of APC activity and from comments Rasmus has made in the >>> bugs (e.g. [1]) this is a safe assumption. >>> >>> * Should APC users switch to opcache and APCu? (with APCu replacing the >>>> APC package) >>>> >>> >>> OPcache is definitely the opcode cache solution for PHP 5.5 >>> >>> For user data caches, there are a number of alternatives, as you >>> noted. During this initial transition phase it isn't clear what the >>> directions of each solution will be. It isn't clear that there will >>> be one dominant solution. I'll leave it to Laruence and Joe to >>> state their cases for world domination of YAC and APCu, respectively. >>> >>> Chris >>> >>> [1] >>> https://bugs.php.net/bug.php?**id=64625<https://bugs.php.net/bug.php?id=64625> >>> >>> >>> For PHP application developers: >>>> * Regarding APCu: it provides the old PHP interface function as well as >>>> their own apcu_* functions. They are aliases right now. Should >>>> application developers think about switching to the apcu_-API as new >>>> features will be available only here? >>>> >>>> Bonus question: >>>> * Right now very similar functionality is provided by APCu, XCache, >>>> WinCache, YAC etc.. Are there plans to include such functionality inside >>>> PHP in future to make application developers life a little easier? At >>>> least a common API would be great. There were several bugs in >>>> applications as these modules behave a little different regarding return >>>> values etc.. >>>> >>>> Greetings, >>>> >>>> Pierre >>>> >>>> >>> >> I am still waiting to see articles/blogs and the consensus on YAC. >> >> YAC has a much higher throughput, if you are able to write the software >> to manage it and have the hardware to put up with it, then you should >> attempt to take advantage. >> >> I'm not really sure if most have either the ability or the hardware; or >> if it's good thing to aspire to having either. Think about what is the >> advantage of using a cache, why does it create a more stable experience >> even when we do have the hardware to SELECT or request everything we >> need from wherever it comes ... it's because you are benefiting from the >> fact that the cache doesn't just make PHP faster because the opcodes >> Zend executes are less than fetching an un-cached result, but also, and >> mostly because it takes the pressure of MySQL, or your network >> connection, or your IO scheduler, or all of the above if you are clever >> about it. The problem with having no locking comes on a loaded server >> when many clients are attempting to read from an expired entry (this is >> the point where a cache has the effect of a stable service even under >> load where items have short ttls) the cache so they can avoid some >> significant work. In that situation, APC (and most others I assume) has >> a lock acquired by the first writer that cannot be obtained by a reader >> while it is held, the writer finishes (populating cache) the reader >> acquires the lock and is able to read that cached item, as are other >> readers. Good, only one context done what the cache is there to avoid. >> With YAC, or any solution that does not employ entry level locking, many >> contexts will end up doing the work, because a reader cannot see what >> isn't finished writing and will not implicitly wait for a write to >> complete. >> >> Something to think about ... >> >> Joe >> > > Not entry level, cache level locking. Entry level I tested and it just > makes the software more complex and work harder for no improvement evident > over read/write locks, and no significant benefit over apcu's > implementation of standard locking (used where rwlocks are disabled > explicitly) ... sorry for missed this message, hehe Yac is designed for user relevant caches, in our applications, cache are always bind to a specific user(cache key is prefix with "user_id"), in this case, Yac is very situable, since there is no "Thundering herd"... for these casese, like cache a config file, once the config file is modified, then multi-process will try to update it. I assume in this case, Yac will get a overhead costs, anyway, I am busy about some else work recently, I will definitly write some blogs/articles about Yaf in reallife applications later. (... and windows support) thanks > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Laruence Xinchen Hui http://www.laruence.com/
