# Multi-level Caching Fork of OPcache -- update - Thread: https://externals.io/message/67297 - Original archive: https://news-web.php.net/php.internals/67297 - Started by Terry Ellison on 2013-05-04T13:29:15+00:00 - Messages: 6 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #67297 — Terry Ellison — 2013-05-04T13:29:15+00:00 URL: https://externals.io/message/67297#67297 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. --- ## #67326 — Dmitry Stogov — 2013-05-07T13:14:01+00:00 URL: https://externals.io/message/67297#67326 · In reply to: #67297 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. > 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-**detailsand a brief quote from the page: > > An indication of the potential performance benefits of OPcache CLI mode > > […] > > 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. --- ## #67372 — Terry Ellison — 2013-05-08T16:25:14+00:00 URL: https://externals.io/message/67297#67372 · In reply to: #67326 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 > 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. > > > […] > 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. --- ## #67670 — Dmitry Stogov — 2013-06-10T08:20:43+00:00 URL: https://externals.io/message/67297#67670 Hi Terry, 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, > > I've just reconciled my test runs for MLC OPcache, and I only had 3 > unexplained test failures. Unfortunately on double-checking against > standard OPcache, they were all due to the core code and not my > additions, so I've raised the corresponding issues. > > I've cc'ed the internals list, but I suspect that my mail ID is still > blacklisted :-( > > Regards Terry > > I've just pushed the latest test version to github and I've now got the > > […] --- ## #67686 — Terry Ellison — 2013-06-11T10:13:27+00:00 URL: https://externals.io/message/67297#67686 · In reply to: #67670 > 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) --- ## #68345 — Dmitry Stogov — 2013-07-31T10:35:48+00:00 URL: https://externals.io/message/67297#68345 · In reply to: #67686 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 wrote: > > > > […] > > 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)