Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67399
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.178 as permitted sender)
MIME-Version: 1.0
Sender: laruence@gmail.com
In-Reply-To: <97.83.29106.0BD1E815@pb1.pair.com>
References: <ec8323fa7c2a52a381bf7c18a8242bb2@archlinux.de>
 <518D5069.90903@oracle.com> <518E1902.9080707@php.net> <97.83.29106.0BD1E815@pb1.pair.com>
Date: Sat, 11 May 2013 20:56:14 +0800
Message-ID: <CABBJUpfEC4qz=kakmipmhOJNx7L2x1sdVawYyKYOvE-CMC5+6g@mail.gmail.com>
To: Joe Watkins <krakjoe@php.net>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c267e4374ce704dc70d014
Subject: Re: [PHP-DEV] PHP 5.5 and APC user cache upgrade path
From: laruence@php.net (Laruence)

--001a11c267e4374ce704dc70d014
Content-Type: text/plain; charset=UTF-8

On Sat, May 11, 2013 at 6:30 PM, Joe Watkins <krakjoe@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/

--001a11c267e4374ce704dc70d014--