Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67397
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: internals@lists.php.net,Christopher Jones <christopher.jones@oracle.com>
Message-ID: <518E1902.9080707@php.net>
Date: Sat, 11 May 2013 11:10:10 +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>
In-Reply-To: <518D5069.90903@oracle.com>
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/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