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?
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.
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.
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:
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
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:
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...
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?)
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:
The calling script would call Exists, which redirects to zend_opcache.Exists
If item is in Zend Opcache's cache, call returns, otherwise, Zend Opcache calls Exists, which redirects to WinCache.Exists
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 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?
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?
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).
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.
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?
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).
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.
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.
+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.
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.
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.
Lex Li
https://lextudio.com
---------------------------
This posting is provided "AS IS" with no warranties, and confers no rights.
27 Posts
PHP 7.2 and future of WinCache
Jun 11, 2017 04:03 AM|DRUE|LINK
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?
352 Posts
Microsoft
Moderator
Re: PHP 7.2 and future of WinCache
Jun 13, 2017 07:48 PM|DropPhone|LINK
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.
27 Posts
Re: PHP 7.2 and future of WinCache
Jun 21, 2017 04:10 AM|DRUE|LINK
Are you going to fix the issues with reroute_enabled and WordPress?
Is this setting useful in any way?
352 Posts
Microsoft
Moderator
Re: PHP 7.2 and future of WinCache
Jul 06, 2017 05:37 PM|DropPhone|LINK
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.
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.
352 Posts
Microsoft
Moderator
Re: PHP 7.2 and future of WinCache
Jul 06, 2017 06:46 PM|DropPhone|LINK
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.
27 Posts
Re: PHP 7.2 and future of WinCache
Jul 16, 2017 06:37 PM|DRUE|LINK
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.
Still on v2.0.0.8? Any plans for a v2.0.0.9?
352 Posts
Microsoft
Moderator
Re: PHP 7.2 and future of WinCache
Jul 24, 2017 06:38 PM|DropPhone|LINK
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.
1 Post
Re: PHP 7.2 and future of WinCache
Aug 02, 2017 12:30 PM|maurosys|LINK
Great!!
I still waiting for suport to PHP 7.2 beta 1 and Beta 2.
352 Posts
Microsoft
Moderator
Re: PHP 7.2 and future of WinCache
Aug 03, 2017 07:15 PM|DropPhone|LINK
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.
27 Posts
Re: PHP 7.2 and future of WinCache
Sep 06, 2017 11:03 PM|DRUE|LINK
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?)
352 Posts
Microsoft
Moderator
Re: PHP 7.2 and future of WinCache
Sep 12, 2017 09:27 PM|DropPhone|LINK
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:
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.
27 Posts
Re: PHP 7.2 and future of WinCache
Sep 12, 2017 10:25 PM|DRUE|LINK
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?
27 Posts
Re: PHP 7.2 and future of WinCache
Sep 12, 2017 11:06 PM|DRUE|LINK
Also, should "inconsistent views of the file system" be a concern when using all these caching layers?
352 Posts
Microsoft
Moderator
Re: PHP 7.2 and future of WinCache
Sep 13, 2017 06:15 PM|DropPhone|LINK
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).
352 Posts
Microsoft
Moderator
Re: PHP 7.2 and future of WinCache
Sep 13, 2017 06:33 PM|DropPhone|LINK
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.
27 Posts
Re: PHP 7.2 and future of WinCache
Oct 04, 2017 04:19 PM|DRUE|LINK
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?
352 Posts
Microsoft
Moderator
Re: PHP 7.2 and future of WinCache
Oct 09, 2017 03:50 PM|DropPhone|LINK
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.
27 Posts
Re: PHP 7.2 and future of WinCache
Nov 09, 2017 05:42 PM|DRUE|LINK
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
27 Posts
Re: PHP 7.2 and future of WinCache
Nov 27, 2017 10:37 PM|DRUE|LINK
Only a few days left now!
4 Posts
Re: PHP 7.2 and future of WinCache
Dec 11, 2017 07:13 AM|Bsweb|LINK
Any more news on this? We are keen for a stable release of wincache for PHP 7.2 too.
352 Posts
Microsoft
Moderator
Re: PHP 7.2 and future of WinCache
Dec 13, 2017 01:25 AM|DropPhone|LINK
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.
4 Posts
Re: PHP 7.2 and future of WinCache
Dec 13, 2017 05:53 AM|Bsweb|LINK
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
352 Posts
Microsoft
Moderator
Re: PHP 7.2 and future of WinCache
Dec 13, 2017 07:17 PM|DropPhone|LINK
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.
27 Posts
Re: PHP 7.2 and future of WinCache
Dec 21, 2017 03:49 AM|DRUE|LINK
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?
https://pecl.php.net/package/wincache
Also need to get that updated source code published too.
3 Posts
Re: PHP 7.2 and future of WinCache
Jan 09, 2018 10:41 PM|TampaCraig|LINK
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
120 Posts
Re: PHP 7.2 and future of WinCache
Jan 26, 2018 10:36 AM|JulienTLD|LINK
Hi,
"Will there be a stable Wincache release for PHP-7.2.x soon?"
Same question for me. Any news Eric ?
Thanks.
352 Posts
Microsoft
Moderator
Re: PHP 7.2 and future of WinCache
Jan 30, 2018 05:55 PM|DropPhone|LINK
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.
120 Posts
Re: PHP 7.2 and future of WinCache
Jan 30, 2018 05:57 PM|JulienTLD|LINK
Good news, thanks ;)
1 Post
Re: PHP 7.2 and future of WinCache
Jun 26, 2018 11:06 AM|pilathraj|LINK
Hi developers/admins,
Any updated for php7.2??
Thanks
Pilathraj A
1 Post
Re: PHP 7.2 and future of WinCache
Aug 17, 2018 03:56 PM|RodLC|LINK
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.
4 Posts
Re: PHP 7.2 and future of WinCache
Sep 20, 2018 10:30 AM|Bsweb|LINK
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?
27 Posts
Re: PHP 7.2 and future of WinCache
Oct 17, 2018 06:55 PM|DRUE|LINK
+1 on some kind of update.
Getting concerned this extension may be EOL!
37 Posts
Re: PHP 7.2 and future of WinCache
Oct 23, 2018 11:39 PM|jchertudi|LINK
+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.
4 Posts
Re: PHP 7.2 and future of WinCache
Dec 12, 2018 10:39 AM|Bsweb|LINK
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.
27 Posts
Re: PHP 7.2 and future of WinCache
Dec 21, 2018 02:08 AM|DRUE|LINK
This is a message I got from the dev over email:
27 Posts
Re: PHP 7.2 and future of WinCache
Apr 19, 2019 10:33 PM|DRUE|LINK
I have lost touch with Eric/DropPhone, he has not responded to multiple emails.
Hope he's busy working on it.
7 Posts
Re: PHP 7.2 and future of WinCache
May 30, 2019 03:44 PM|topogigio|LINK
so no more php on IIS? :(
10 Posts
Re: PHP 7.2 and future of WinCache
May 30, 2019 05:01 PM|Anamera|LINK
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.
8386 Posts
MVP
Re: PHP 7.2 and future of WinCache
May 31, 2019 04:22 AM|lextm|LINK
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,
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,
PHP on Linux is always an option for you, and Microsoft supports PHP on Linux on Azure in many ways.
https://lextudio.com
---------------------------
This posting is provided "AS IS" with no warranties, and confers no rights.
37 Posts
Moderator
Re: PHP 7.2 and future of WinCache
Jun 18, 2019 01:03 AM|mbanavige|LINK
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