PHP 5.5 and APC user cache upgrade path

12 years ago by Pierre Schmitz — view source — reply

unread

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?
Should APC users switch to opcache and APCu? (with APCu replacing the
APC package)

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

--
Pierre Schmitz, https://pierre-schmitz.com

12 years ago by Dan Cryer — view source — reply

unread

I'm also very keen to understand the expected upgrade path, but from the
perspective of a PHP developer supporting some large bespoke applications
that rely heavily both on opcode caching and the user-caching functionality
of APC.

Is APCu the agreed best path for systems that currently use APC's user
cache?

Dan Cryer

07590 698944
dan@dancryer.com
+Dan https://plus.google.com/101400775372325517263
@dancryer <http://www.twitter.com/dancryer

12 years ago by Laruence — view source — reply

unread

Hey:

besides APCu,  you can also have a try with :

https://github.com/laruence/yac :)

thanks

--
Laruence Xinchen Hui
http://www.laruence.com/

12 years ago by Joe Watkins — view source — reply

unread

Working backwards: I personally don't see a reason for user caches to be
in the core, not least of all there are multiple solutions, all suitable
and some still maintained. The reason I think it's not really a core
feature is that caching of user variables is something that must be
explicit in an application, whereas opcode caching and the optimization
that opcache performs should be a standard part of the compilation stage
of execution, so fits better in the core.

There's no merit to the argument that opcache and APC/YAC/whatever could
share shm logic: the kind of implementation that APC(u) and opcache need
are very different, right now they both have a suitable allocator.
Furthermore, YAC implements (a very clever) completely different way of
allocating shared memory, which should be tested on it's own merit in
the real world before I consider implementing it's allocator in APCu.

By default, APCu builds in an APC-compatible manner, emulating the old
functions for APC, no change should be required to run legacy code
relying on APC.
New features, if they are written, will not be included in the APCu
codebase, instead, APCu exposes all of it's API to other extensions,
which allows any future features to be written and maintained completely
separately, which I think to be a better solution as APC is in such
heavy use.

Very few people are able to helpfully maintain an opcode cache, the idea
of including opcache in the core, or one of the ideas/benefits, is that
everyone able can concentrate on one solution, implicitly APC will fall
by the wayside where opcode caching is concerned. However, it is
possible to run APC and opcache side by side by fiddling with ini
settings, I can't really say if this is advisable or not, a possibility
all the same.

I think that's everything ...

12 years ago by Christopher Jones — view source — reply

unread

From the lack of APC activity and from comments Rasmus has made in the
bugs (e.g. [1]) this is a safe assumption.

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

--
christopher.jones@oracle.com http://twitter.com/ghrd
Newly updated, free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html

12 years ago by Joe Watkins — view source — reply

unread

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

12 years ago by Joe Watkins — view source — reply

unread

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) ...

12 years ago by Laruence — view source — reply

unread

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

--
Laruence Xinchen Hui
http://www.laruence.com/