Multi-level Caching Fork of OPcache -- update View as Markdown

Dmitry,

Hi Terry,

I don't have time right now (on this week), but I'll definitely take a
look into your patch later.

Thanks. Dmitry.

Hi and thanks for this. I won't have the full functionality in place
for another month or so, though my pushes to my github repository should
be fully functional on the main path and subject to caveats in the TODO,
etc., so it's just more general guidance when you get time, e.g I would
be happier if you approached X this way, or don't forget to address
issue Y which we've been burnt on in the past...

Also have a scan through the wiki pages for B/G design info. If you
guys want, I could also do the equivalent for standard OPcache down the
line, since I know have a pretty intimate knowledge of how it works; I
would just need to know the target audience that you would like to address.

Regards
Terry

On Sat, May 4, 2013 at 5:29 PM, Terry Ellison <Terry@ellisons.org.uk
mailto:Terry@ellisons.org.uk> wrote:

Please treat this email by way of request for feedback from the
OPcache developers and anyone interested in influencing my next
steps on my https://github.com/TerryE/opcache fork of OPcache and
specifically on the dev-filecache branch.  The most appropriate
channel is probably https://github.com/TerryE/opcache/issues --
unless you think that the comments have wider applicability for
either the PECL or DEV communities.

My ultimate aim is to take this to a point where the OPcache
developers feel sufficiently comfortable to consider merging a
future version back into OPcache.  I have added some detailed
project wiki pages documenting my scope and progress and in
particular on
https://github.com/TerryE/opcache/wiki/MLC-OPcache-details and a
brief quote from the page:

    An indication of the potential performance benefits of OPcache
    CLI mode can be seen from a simple benchmark based on 100
    executions of the MediaWiki runJobs.php maintenance batch
    script. This compiles some 44 PHP sources, comprising 45K
    lines and 1,312 Kbytes. The cached version reads a single
    runJobs.cache file of 1,013 Kbytes.

     Time in mSec         Average  Stdev
     Uncached Execution     179      7
     Cached Execution        77      7
     (Image Load Overhead)   18      3


In other words for this script, the MLC cache is delivering an
approximate 60% runtime saving.  Of course this is only a point
test, and benefits will vary -- though I hope that switching to
LZ4 compression will improve these figures further.  But even this
one point challenges what seems to be a core PHP development
dogma: "there's no point in using a file cache, because it makes
no material performance difference".   Even this build *does*
deliver material benefits , and I suggest that there is merit in
moving to including MLC cached modes to accelerate CLI and GCI
SAPI modes using this or a similar approach.

>From an internals -- rather than PECL -- viewpoint what this
would mean is that non-cached incremental compile-and-go execution
modes would now be the exception than the norm -- largely negating
the disadvantages of any compile-intensive optimization options.

So thank-you in anticipation for your feedback.  I will do my
utmost to respond constructively to all comments. :-)
Regards Terry Ellison

PS.  Apologies in advance:  I am "up country" at my cottage on an
Island in the north Aegean with the nearest Wifi some walk away,
so my Internet access is limited at the moment, and I might take
some time to respond.

I agree with both (A) and (B).

However (B) was done on purpose and has its advantages and disadvantages.
Anyway, I've opened https://github.com/zendtech/ZendOptimizerPlus/issues/118

C) file based opcode caching may be interesting as well

but all these requests are going to be a part of next major release (may be
in php-5.6)

Thanks. Dmitry.

Thanks. Dmitry.

On Tue, Jun 11, 2013 at 2:13 PM, Terry Ellison ellison.terry@gmail.comwrote:

Sorry for slow response.
I'm very busy with other work and have no time for MLC OPcache review.
I don't think we can include it into main tree before 5.5.0 release
anyway.
But in general I think we may include your work in the future releases.

Also, thanks for useful reports about problems you've found in OPcache :)

Thanks. Dmitry.

Dmitry,

One useful side-effect of writing the MLC support is that I've really had
to take apart the core OPcache code to understand how it works. It's
probably the first in-depth review that this extension has had from someone
outside the Zend team, so its only to be expected that anyone doing this
would find a few issues.

What I do think needs to be said it that I think that you guys have done a
fantastic job here in this development. 9 times out of 10 when I've
initially thought "why didn't they do it this way?" when digging into the
code, I've dug down in and discovered that you already had, or had
approached it a better way. IMO, the whole OPcache approach is tighter and
more sound than that of APC. Take one example of this: the 2-pass algo for
compiled scripts which enables the storage for a compiled script be to
allocated as a single storage unit. This has two major performance
benefits at runtime:

1. The memory allocator overheads of preparing scripts for execution (and
   deallocation at rundown) are reduced by more than an order of magnitude.
2. The memory needed to execute the script is in a contiguous memory
   areas, and this gives improved hardware (as in L1/L2/L3) caching which
   passes through to a runtime performance improvement.

There are a couple of things that I would refactor if I had written
OPcache. (I'll raise a couple of issues on these to discuss what I mean in
more depth. and when the MLC work reaches a plateau if you think its
worthwhile I can cut a couple of branches to show you a possible solution.)
A) The SMA startup bootstrap is just messy and needs refactoring.
B) The simple dead-and-rebirth method of refreshing caches isn't going to
scale well on real systems.

Terry
(Note the new email addr that I am using for php.net work, as this one
isn't being blocked by the php.net server)