locked
PHP 7.2 and future of WinCache RRS feed

  • Question

  • User-1458132148 posted

    Hi developers/admins,

    PHP 7.2 alpha is out! Any news for WinCache support? Additionally, what is the future of this extension? Has it been abandoned? I haven't been able to find any roadmaps or features in development. This extension greatly improves my site and I hope it will continue to be developed!

    Last update was November 2016! What's coming in 2.0.0.9 and beyond?Cool

    Sunday, June 11, 2017 4:03 AM

All replies

  • User409000176 posted

    WinCache is still supported.  I need to spend some cycles to setup a PHP 7.2 build tree and rebuild WinCache for 7.2.  Hopefully they haven't changed the internals too much this time around.

    I'm planning to have a WinCache for PHP 7.2 build available before PHP 7.2 releases.  Since they haven't yet hit feature freeze, there could still be some churn that would affect the extensions (where I got burned before during the PHP 7.1 cycle).  I'll probably wait until they've promised they won't rev the key internals before I put out a build.

    As for roadmap, it's pretty simple.  If people find bugs I can fix, I fix them.  ;)

    Thx!

        --E.

    [Edit]

    After reviewing the PHP 7.2 timetable, I will target having a WinCache for PHP 7.2 build after PHP 7.2 Beta 1 is released.

    Tuesday, June 13, 2017 7:48 PM
  • User-1458132148 posted

    Are you going to fix the issues with reroute_enabled and WordPress?

    Is this setting useful in any way?

    Wednesday, June 21, 2017 4:10 AM
  • User409000176 posted

    Are you going to fix the issues with reroute_enabled and WordPress?

    To which issue are you referring?  I'm not aware of an issue with reroute_enabled + WordPress.  Please send reports/links to me via private message.

    I've heard of issues with reroute_enabled + Drupal, but nothing about WordPress.  I'm investigating the Drupal issues as time permits.

    Is this setting useful in any way?

    If you are working off a local file system (an actual disk on the local machine), then not so much.  However, if you are working on a network drive or remote file system, then reroute_enabled absolutely makes a difference. 

    The challenge with reroute_enabled is there are dozens of file-related PHP functions, and WinCache only hooks the most frequently used ones to improve performance.  Over the past few years I've added hooks for a couple more, just to get WordPress and a couple of other frameworks to work.  However, if your PHP code uses other, unhooked I/O functions in combination with hooked functions, then you'll get inconsistent views of the file system, and that's ultimately what causes things to go sideways.

    Thx!

        --E.

    Thursday, July 6, 2017 5:37 PM
  • User409000176 posted

    After reviewing the PHP 7.2 timetable, I will target having a WinCache for PHP 7.2 build after PHP 7.2 Beta 1 is released.

    It looks like they've locked the PHP_API_VERSION, ZEND_MODULE_API_NO and ZEND_EXTENSION_API_NO, so it's safe to put out a WinCache build for PHP 7.2.0alpha3:

    x64: https://sourceforge.net/projects/wincache/files/development/wincache-2.0.0.8-dev-7.2.alpha3-nts-vc15-x64.exe/download

    x86: https://sourceforge.net/projects/wincache/files/development/wincache-2.0.0.8-dev-7.2.alpha3-nts-vc15-x86.exe/download 

    Thx!

        --E.

    Thursday, July 6, 2017 6:46 PM
  • User-1458132148 posted

    DRUE

    Are you going to fix the issues with reroute_enabled and WordPress?

    To which issue are you referring?  I'm not aware of an issue with reroute_enabled + WordPress.  Please send reports/links to me via private message.

    I've heard of issues with reroute_enabled + Drupal, but nothing about WordPress.  I'm investigating the Drupal issues as time permits.

    I had issues with it before. I believe with plugin updates - it's been a while.. I'll re-test and PM you any reports.

    DropPhone

    After reviewing the PHP 7.2 timetable, I will target having a WinCache for PHP 7.2 build after PHP 7.2 Beta 1 is released.

    It looks like they've locked the PHP_API_VERSION, ZEND_MODULE_API_NO and ZEND_EXTENSION_API_NO, so it's safe to put out a WinCache build for PHP 7.2.0alpha3:

    x64: https://sourceforge.net/projects/wincache/files/development/wincache-2.0.0.8-dev-7.2.alpha3-nts-vc15-x64.exe/download

    x86: https://sourceforge.net/projects/wincache/files/development/wincache-2.0.0.8-dev-7.2.alpha3-nts-vc15-x86.exe/download 

    Thx!

        --E.

    Still on v2.0.0.8? Any plans for a v2.0.0.9?

    Sunday, July 16, 2017 6:37 PM
  • User409000176 posted

    Still on v2.0.0.8? Any plans for a v2.0.0.9?

    I have some bug fixes I'm working on, so yes, there will be a v2.0.0.9, as time permits.  I can't promise an ETA.

    Monday, July 24, 2017 6:38 PM
  • User419184053 posted

    Great!!

    I still waiting for suport to PHP 7.2 beta 1 and Beta 2.

    Wednesday, August 2, 2017 12:30 PM
  • User409000176 posted

    maurosys

    I still waiting for suport to PHP 7.2 beta 1 and Beta 2.

    Ah, looks like they changed the PHP_API_VERSION, ZEND_MODULE_API_NO and ZEND_EXTENSION_API_NO when they forked the 7.2 branch.  Forces us extension authors to recompile yet again...

    Here's the PHP7.2.beta2 bits:

    x86: https://sourceforge.net/projects/wincache/files/development/wincache-2.0.0.8-dev-7.2.beta2-nts-vc15-x86.exe/download
    x64: https://sourceforge.net/projects/wincache/files/development/wincache-2.0.0.8-dev-7.2.beta2-nts-vc15-x64.exe/download

    Thx!

        --E.

    Thursday, August 3, 2017 7:15 PM
  • User-1458132148 posted

    DRUE

    Are you going to fix the issues with reroute_enabled and WordPress?

    To which issue are you referring?  I'm not aware of an issue with reroute_enabled + WordPress.  Please send reports/links to me via private message.

    I've heard of issues with reroute_enabled + Drupal, but nothing about WordPress.  I'm investigating the Drupal issues as time permits.

    DRUE

    Is this setting useful in any way?

    If you are working off a local file system (an actual disk on the local machine), then not so much.  However, if you are working on a network drive or remote file system, then reroute_enabled absolutely makes a difference. 

    The challenge with reroute_enabled is there are dozens of file-related PHP functions, and WinCache only hooks the most frequently used ones to improve performance.  Over the past few years I've added hooks for a couple more, just to get WordPress and a couple of other frameworks to work.  However, if your PHP code uses other, unhooked I/O functions in combination with hooked functions, then you'll get inconsistent views of the file system, and that's ultimately what causes things to go sideways.

    Thx!

        --E.

    Out of curiosity, what would happen if opcache.enable_file_override and reroute_enabled were both on?

    opcache.enable_file_override hooks file_exists, is_file, and is_readable.

    If both are on, will bad things happen, or will only one override handler be used? (Which?)

    Wednesday, September 6, 2017 11:03 PM
  • User409000176 posted

    Out of curiosity, what would happen if opcache.enable_file_override and reroute_enabled were both on?

    Good question!

    The way PHP Core lets developers hook functions is by chaining to the existing value.  In this case, Zend Opcache is special, in that it's a zend_extension, and therefore gets first/final crack at all the hooks.  Which means Zend Opcache is the last one to hook things, which ensures it's always called first when a hooked function is called.

    If both WinCache and Zend Opcache are hooking the Exists() function, it would look like this:

    [calling script]
    |
    | -- zend_opcache.Exists | |-- WinCache.Exists | |-- PHPCore.Exists
    1. The calling script would call Exists, which redirects to zend_opcache.Exists
    2. If item is in Zend Opcache's cache, call returns, otherwise, Zend Opcache calls Exists, which redirects to WinCache.Exists
    3. If item is in WinCache's cache, call returns. Otherwise, WinCache calls Exists, which redirects to PHPCore.Exists

    Here's the thing: Zend Opcache's cache and WinCache's file cache contain different, but overlapping, items.  Zend Opcache's cache contains only *.php script files.  WinCache's file cache contains anything that was opened via the PHP streams interface. 

    So, let's walk through a couple of examples:

    A script starts executing.  PHP Core calls Compile script (remember, it's an interpreted language!  PHP must call compile every single time a script is executed in order to get the array of Intermediate Language opcodes).  The Compile function is actually hooked by Zend Opcache, which checks to see if the opcode array for the script was previously cached.  In this example, it hasn't.  Zend Opcache calls the PHP Core compile, which reads the *.php script file via the streams interface, which WinCache has hooked.  WinCache checks to see if the stream exists in its file cache (which, for this example, it hasn't).  WinCache calls the PHP Core stream APIs, and caches the result.  PHP Core parses, compiles, optimizes, and returns the opcode array to Zend Opcache, which caches it. Then, PHP Core executes the script.

    Second example:

    A script calls Readfile('foo.txt'), which is actually hooked by WinCache.  WinCache.Readfile checks to see if the file exists in its cache.  If it does, it returns it.  If it hasn't, it calls the PHP Core Readfile('foo.txt'), and caches the result before returning to the script.

    Third example:

    A script calls file_exists('foo.txt'), which redirects to Zend Opcache's file_exists.  Zend Opcache looks to see if it has the file cached.  It won't, because it's not a *.php file, so it calls the next file_exists(), which redirects to WinCache's file_exists.  If WinCache has the file cached, it will return TRUE.  If it's not cached, it calls the PHP Core file_exists().  NOTE: Neither WinCache nor Zend Opcache maintain a "negative cache"!  Which means that if PHP Core file_exists() returns FALSE, neither WinCache nor Zend Opcache will cache that FALSE result.  This is because there are many, many ways for a script to create a file that it becomes prohibitive to hook all the different ways and 100% accurately detect when a file is created.  So, do yourself a favor, and try not to call file_exists() all over the place for files you know don't exist.  It's painful, and hits every component that hooks the file_exists() function before eventually hitting the file system.

    I hope this helps!

        --E.

    Tuesday, September 12, 2017 9:27 PM
  • User-1458132148 posted

    Amazing answer, thank you so much!

    I will have opcache.enable_file_override, reroute_enabled, and fcenabled enabled. I'll let you know if I run into any problems.. do you expect to see any with these settings on WordPress?

    Tuesday, September 12, 2017 10:25 PM
  • User-1458132148 posted

    The challenge with reroute_enabled is there are dozens of file-related PHP functions, and WinCache only hooks the most frequently used ones to improve performance.  Over the past few years I've added hooks for a couple more, just to get WordPress and a couple of other frameworks to work.  However, if your PHP code uses other, unhooked I/O functions in combination with hooked functions, then you'll get inconsistent views of the file system, and that's ultimately what causes things to go sideways.

    Also, should "inconsistent views of the file system" be a concern when using all these caching layers?

    Tuesday, September 12, 2017 11:06 PM
  • User409000176 posted

    I will have opcache.enable_file_override, reroute_enabled, and fcenabled enabled. I'll let you know if I run into any problems.. do you expect to see any with these settings on WordPress?

    No.

    There are some known issues with Drupal + wincache.reroute_enabled=1, so I can't whole-heartedly recommend reroute_enabled in that scenario.  But WordPress is the majority case on Azure Web Apps, which is where WinCache gets the most coverage (and scrutiny).

    Wednesday, September 13, 2017 6:15 PM
  • User409000176 posted

    should "inconsistent views of the file system" be a concern when using all these caching layers?

    Any caching system must present a coherent view of the resources it caches.  With PHP, there's many ways to interact with the file system.  The balance when implementing the WinCache file cache is to pick the right set of APIs to hook to ensure coherence.  So, we quickly analyzed the various frameworks (plus the popular extensions for those frameworks) and picked the APIs that would make them work.

    And, of course, the frameworks changed, using different PHP file APIs, so it became a moving target to hook new APIs.  I think the original set was the stream APIs plus rmdir().  Now it's streams API plus 12 APIs.  And there are still some weird usage patterns in Drupal that I still need to investigate.

    Thx!

        --E.

    Wednesday, September 13, 2017 6:33 PM
  • User-1458132148 posted

    I've discovered after testing the speed of installing and deleting the Jetpack WordPress plugin, reroute_enabled actually slows things down by a few seconds if it is ON.

    Install speed OFF: 13-14 seconds

    Install speed ON: 16-17 seconds

    Delete speed OFF: 3-4 seconds

    Delete speed ON: 6-7 seconds

    Any insight as to why? I question the usefulness of the feature if it doesn't speed things up.

    Furthermore, I also disabled WinCache entirely and the "OFF" speeds above remained consistent as to what was showing with WinCache enabled and file cache on. Has PHP finally figured out how to speed up their code without WinCache being there to help?

    Wednesday, October 4, 2017 4:19 PM
  • User409000176 posted

    If you have enabled Zend Opcache, and your wordpress site extension is performing its own file caching, then you won't see much of an improvement.

    WinCache is just a caching layer.  So, unless you're installing and uninstalling the Jetpack plugin on every single request, I'm not sure that WinCache is the right thing for speeding up that operation.  However, I can't see how adding the reroute_enabled = true would slow a request down by 3 seconds.  I'd be interested in seeing the perf analysis of that operation (with Valgrind/Cachegrind/XDebug).

    If the file system is entirely local to the server, then the benefits of reroute_enabled aren't as significant (the file system cache will sometimes work just as well).  Where the reroute_enabled really helps is when your file system is remote (SMB/NFS).

    Hope this helps!

        --E.

    Monday, October 9, 2017 3:50 PM
  • User-1458132148 posted

    Can you get a new WinCache ready for PHP 7.2? RC6 is here, and they say "Nov 30th's GA release being not-substantially different."

    http://php.net/archive/2017.php#id2017-11-09-1

    Thursday, November 9, 2017 5:42 PM
  • User-1458132148 posted

    Only a few days left now!

    Monday, November 27, 2017 10:37 PM
  • User-596103661 posted

    Any more news on this? We are keen for a stable release of wincache for PHP 7.2 too.

    Monday, December 11, 2017 7:13 AM
  • User409000176 posted

    I just tested, and the 2.0.0.8 WinCache out on sourceforge still works with PHP 7.2.0 released version.  Please feel free to continue using it.

    There have been no changes since it was built.

    Thx!

        --E.

    Wednesday, December 13, 2017 1:25 AM
  • User-596103661 posted

    I am afraid the x64 doesn't

    [13-Dec-2017 05:52:20 UTC] PHP Warning:  PHP Startup: wincache: Unable to initialize module

    Module compiled with module API=20160303

    PHP    compiled with module API=20170718

    These options need to match

     in Unknown on line 0

    Thanks,
    Chris

    Wednesday, December 13, 2017 5:53 AM
  • User409000176 posted

    I have tested https://sourceforge.net/projects/wincache/files/development/wincache-2.0.0.8-dev-7.2.beta2-nts-vc15-x64.exe/download with v7.2.0 from http://windows.php.net/downloads/releases/php-7.2.0-nts-Win32-VC15-x64.zip , and it appears to work.  Can you please retry with the WinCache from the link above?

    Thx!

        --E.

    Wednesday, December 13, 2017 7:17 PM
  • User-1458132148 posted

    I still find it strange you put the 7.2 release in a place not many people will care to look.

    Why isn't the 7.2 WinCache on PECL yet?surprised https://pecl.php.net/package/wincache

    Also need to get that updated source code published too.

    Thursday, December 21, 2017 3:49 AM
  • User603283467 posted

    I've been testing Released /development/wincache-2.0.0.8-dev-7.2.beta2-nts-vc15-x86.exe  with PHP 7.2.1 and it seems to be working well. will there be a stable Wincache release for PHP-7.2.x soon?

    BTW, thank for your work on this great extension, it make my report-heavy Intranet sing!!! It is saving my SQL  server a load of load and traffic.

    Craig

    Tuesday, January 9, 2018 10:41 PM
  • User-1364852999 posted

    Hi,

    "Will there be a stable Wincache release for PHP-7.2.x soon?"

    Same question for me. Any news Eric ?

    Thanks.

    Friday, January 26, 2018 10:36 AM
  • User409000176 posted

    I'll start working on updating the WebPI Feed soon.  I can't give an ETA, as other things may preempt my time.  Hoping to get this cranked out in the next couple of weeks.

    Thx!

         --E. 

    Tuesday, January 30, 2018 5:55 PM
  • User-1364852999 posted

    Good news, thanks ;)

    Tuesday, January 30, 2018 5:57 PM
  • User778776066 posted

    Hi developers/admins,

    Any updated for php7.2??

    Thanks 

    Pilathraj A

    Tuesday, June 26, 2018 11:06 AM
  • User-1439596425 posted

    Wanted to ask for an update on WinCache-2.0.0.8 for PHP 7.2 official release? Many are unable to bring a beta tested software package into their environment and are forced to use an older version.   Please provide an update on the publishing of the new release that has been fully tested with 7.2. Thanks.

    Friday, August 17, 2018 3:56 PM
  • User-596103661 posted

    Just thought I'd give this another bump. Any news on a release versions of WinCache for PHP 7.2?

    Also PHP 7.3 is in RC now with RC 2 due September 27th 2018. Any news on support for that?

    Thursday, September 20, 2018 10:30 AM
  • User-1458132148 posted

    +1 on some kind of update.

    Getting concerned this extension may be EOL!

    Wednesday, October 17, 2018 6:55 PM
  • User808724780 posted

    +1 from me as well. I'm planning to improve performance for our IIS PHP MSSQL app even more with wincache, after just getting a nice boost from php 7.2.

    In our dev environment we are running wincache-2.0.0.8-dev-7.2.beta2-nts-vc15-x86

    hoping to take more advantage of it in winter, possibly putting php code on network storage. Network storage for code was a poor performer under php 5, many years ago.

    Tuesday, October 23, 2018 11:39 PM
  • User-596103661 posted

    Another bump with release of PHP 7.3 earlier this month.

    Any news?

    Don't mind either way but an update would be good. Thanks.

    Wednesday, December 12, 2018 10:39 AM
  • User-1458132148 posted

    This is a message I got from the dev over email:

    Yes, this is on our radar, but prioritized behind several other work items.

    Also, since the internals for 7.3 changed, it will take a bit more effort than simply recompiling.  I can't give an ETA for this work yet.

    Friday, December 21, 2018 2:08 AM
  • User-1458132148 posted

    I have lost touch with Eric/DropPhone, he has not responded to multiple emails.cry

    Hope he's busy working on it.

    Friday, April 19, 2019 10:33 PM
  • User-1837510449 posted

    so no more php on IIS? :(

    Thursday, May 30, 2019 3:44 PM
  • User-1165664085 posted

    I'm confused, the download page for WinCache claims it's "Microsoft Supported"? Didn't see an 'End of Support' notice?

    By now, PHP 7.3 is 6 months out of release (and of course plenty of alpha and beta versions prior), and it's already up to 7.3.6. 

    Thursday, May 30, 2019 5:01 PM
  • User690216013 posted

    Readers of such threads should be warned about the history of PHP on IIS. (I blogged about the beginning in my blog post https://blog.lextudio.com/history-of-php-manager-for-iis-7e29bd9828f0) So in short, bringing PHP to IIS was a move to enable PHP on Windows Azure, now Microsoft Azure. However, the introduction of Azure App Service on Linux recently made it less important to support PHP on IIS.

    We already see Microsoft deprecated its efforts on Python on IIS, https://blog.lextudio.com/shifting-to-azure-app-service-on-linux-b216f4584b03 So Windows Python users should switch to Linux, or they have to maintain components like WFastCGI themselves.

    The PHP story is similar, but FastCGI for PHP components are,

    • FastCGI support as part of IIS.
    • PHP-CGI as part of PHP Windows distribution.

    So as long as Microsoft ships IIS, and PHP community ships their Windows distribution, you might continue to use PHP on Windows/IIS.

    But the components like WinCache has its risks, as they are separate open source projects (just like WFastCGI for Python), https://github.com/php/pecl-caching-wincache/network Microsoft might stop moving such open source projects forward (as they shifted focus to Azure Linux) one day, so as users of them you should be prepared to take them over,

    • If the most recent release (2.0.0.8) fails for a future PHP release (7.3?) or future Windows releases
    • Or if Microsoft publishes a similar announcement to deprecate its PHP components for Windows

    PHP on Linux is always an option for you, and Microsoft supports PHP on Linux on Azure in many ways.

    Friday, May 31, 2019 4:22 AM
  • User-158764254 posted

    There is a WinCache update for PHP 7.3 and PHP 7.4alpha1 !

    Let's all move the discussion to the new announcement thread here.

    https://forums.iis.net/t/1242776.aspx?+Pre+Release+WinCache+for+PHP+7+3+and+PHP+7+4alpha1

    Tuesday, June 18, 2019 1:03 AM