Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67398
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <97.83.29106.0BD1E815@pb1.pair.com>
To: internals@lists.php.net
Date: Sat, 11 May 2013 11:30:06 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4
MIME-Version: 1.0
References: <ec8323fa7c2a52a381bf7c18a8242bb2@archlinux.de> <518D5069.90903@oracle.com> <518E1902.9080707@php.net>
In-Reply-To: <518E1902.9080707@php.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PHP 5.5 and APC user cache upgrade path
From: krakjoe@php.net (Joe Watkins)

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
>>
>>
>>> 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) ...