Hi,
can someone please compile a 64-bit version (NTS) for PHP 5.5. Possibly even with the op-code cache completely removed? I would love to move to 64-bit rather sooner than later.
Cheers,
Mike
Hi,
can someone please compile a 64-bit version (NTS) for PHP 5.5. Possibly even with the op-code cache completely removed? I would love to move to 64-bit rather sooner than later.
Cheers,
Mike
Hello,
I have read that the function described here:
http://www.php.net/manual/en/wincache.reroutes.php
could offer better performance than the php built-in ones on Windows.
Is there a way to have the built-in php functions replaced with this one, without enabling wincache as a all please ?
The problem is that we are developping on Wamp (so no fastcgi + in 64 bits) so we can't use wincache easily, and the only issue we have so far is the performance of filemtime and file_exists, so that would be great to enable only those function.
Thanks in advance for your answer
Best regards,
Christophe
Using PHP v5.2.17 with wincache v1.2.614.0 Windows Server 2008 x64
when deploying application all files are published to a build folder, after that a symblic link is created to the newest version in that folder, and IIS loads latest version of application without any down time. The issue here is that wincache does not detect changed files maybe due to symbolic link to a folder, and fatal errors are produced, that some methods are not found or class constants, but they are there. If you open php files you can see that the code is there, and if you restart IIS opt code cache is flushed and everything starts working again.
错误应用程序 php-cgi.exe,版本 5.2.11.11,时间戳 0x4ab13019,错误模块 php_wincache.dll,版本 1.0.1012.0,时间戳 0x4ad39bd7,异常代码 0xc0000005,错误偏移量 0x0000294d, 进程 ID 0x5ec,应用程序启动时间 0x01ca527533907c77。
<div class=e> <div style="TEXT-INDENT: -2em; MARGIN-LEFT: 1em" class=c>-<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"></div><div> <div class=e> <div style="TEXT-INDENT: -2em; MARGIN-LEFT: 1em" class=c>-<System></div> <div> <div class=e> <div style="TEXT-INDENT: -2em; MARGIN-LEFT: 1em"> <ProviderName="Application Error" /></div></div> <div class=e> <div style="TEXT-INDENT: -2em; MARGIN-LEFT: 1em"> <EventID Qualifiers="0">1000</EventID></div></div> <div class=e> <div style="TEXT-INDENT: -2em; MARGIN-LEFT: 1em"> <Level>2</Level></div></div> <div class=e> <div style="TEXT-INDENT: -2em; MARGIN-LEFT: 1em"> <Task>100</Task></div></div> <div class=e> <div style="TEXT-INDENT: -2em; MARGIN-LEFT: 1em"> <Keywords>0x80000000000000</Keywords></div></div> <div class=e> <div style="TEXT-INDENT: -2em; MARGIN-LEFT: 1em"> <TimeCreatedSystemTime="2009-10-21T17:44:07.000Z" /></div></div> <div class=e> <div style="TEXT-INDENT: -2em; MARGIN-LEFT: 1em"> <EventRecordID>1321083</EventRecordID></div></div> <div class=e> <div style="TEXT-INDENT: -2em; MARGIN-LEFT: 1em"> <Channel>Application</Channel></div></div> <div class=e> <div style="TEXT-INDENT: -2em; MARGIN-LEFT: 1em"> <Computer>WIN-CRGEDSMZFWC</Computer></div></div> <div class=e> <div style="TEXT-INDENT: -2em; MARGIN-LEFT: 1em"> <Security/></div></div> <div> </System></div></div></div> <div class=e> <div style="TEXT-INDENT: -2em; MARGIN-LEFT: 1em" class=c>-<EventData></div> <div> <div class=e> <div style="TEXT-INDENT: -2em; MARGIN-LEFT: 1em"> <Data>php-cgi.exe</Data></div></div> <div class=e> <div style="TEXT-INDENT: -2em; MARGIN-LEFT: 1em"> <Data>5.2.11.11</Data></div></div> <div class=e> <div style="TEXT-INDENT: -2em; MARGIN-LEFT: 1em"> <Data>4ab13019</Data></div></div> <div class=e> <div style="TEXT-INDENT: -2em; MARGIN-LEFT: 1em"> <Data>php_wincache.dll</Data></div></div> <div class=e> <div style="TEXT-INDENT: -2em; MARGIN-LEFT: 1em"> <Data>1.0.1012.0</Data></div></div> <div class=e> <div style="TEXT-INDENT: -2em; MARGIN-LEFT: 1em"> <Data>4ad39bd7</Data></div></div> <div class=e> <div style="TEXT-INDENT: -2em; MARGIN-LEFT: 1em"> <Data>c0000005</Data></div></div> <div class=e> <div style="TEXT-INDENT: -2em; MARGIN-LEFT: 1em"> <Data>0000294d</Data></div></div> <div class=e> <div style="TEXT-INDENT: -2em; MARGIN-LEFT: 1em"> <Data>5ec</Data></div></div> <div class=e> <div style="TEXT-INDENT: -2em; MARGIN-LEFT: 1em"> <Data>01ca527533907c77</Data></div></div> <div> </EventData></div></div></div> <div> </Event></div></div></div>
I have a value in the cache right now, that should be expired. Here is the info value:
Array ( [total_cache_uptime] => 86440 [is_local_cache] => [total_item_count] => 118523 [total_hit_count] => 2906916 [total_miss_count] => 427072 [ucache_entries] => Array ( [1] => Array ( [key_name] => Apps_Home::getLists [value_type] => string [value_size] => 881 [ttl_seconds] => 300 [age_seconds] => 20703 [hitcount] => 729 ) ) )
As you can see, age_seconds is WAY over the ttl_seconds value. Why it entry still being returned??
Well, things went well for about 2 weeks and now we have a serious problem. After being up and running for around 3 days, IIS begins to lock up. Our Current Non-Anonymous user count (we are using Windows Authentication) goes from 10 to about 60. Eventually, we get timeout errors, all pointing to wincache_ucache_get() or wincache_ucache_set() lines in the code, and the 500 Internal Server errors. The only solution we have is iisreset!
This is a huge problem and we're not even sure how to troubleshoot it.
Hi,
Every 1-2 weeks, one of my server's websites grinds to a halt.
Looking at windows application event log, I see multiple errors like the one listed below.
I am using Win2008 server with IIS 7.5 64bit, PHP WinCache 1.3.5, PHP 5.5.8.
When this happens, I can also see 10's of php-cgi.exe tasks running (a lot more than when the server is functioning properly).
I will try using WinCache 1.3.5.2 that I see was released as a dev version and see if this error still repeats.
Here's the event log xml data:
<System>
<Provider Name="Application Error" />
<EventID Qualifiers="0">1000</EventID>
<Level>2</Level>
<Task>100</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2014-03-19T09:51:05.000000000Z" />
<EventRecordID>63754</EventRecordID>
<Channel>Application</Channel>
<Computer>HIGHTOURS</Computer>
<Security />
</System>
- <EventData>
<Data>php-cgi.exe</Data>
<Data>5.5.8.0</Data>
<Data>52cde23c</Data>
<Data>php_wincache.dll</Data>
<Data>1.3.5.0</Data>
<Data>51f7ead2</Data>
<Data>c0000005</Data>
<Data>00007ff3</Data>
<Data>c1c</Data>
<Data>01cf4358bef65452</Data>
<Data>C:\Program Files (x86)\PHP\v5.5\php-cgi.exe</Data>
<Data>C:\Program Files (x86)\PHP\v5.5\ext\php_wincache.dll</Data>
<Data>fca07dd2-af4b-11e3-af09-95187af0dd16</Data>
</EventData>
</Event>
For people who are experiencing 500 errors with crashes in Wincache, I would like your help in investigating something.
It turns out that the IIS FastCGI handler will terminate requests that take too long. The default for this is 90 seconds. (see: http://www.iis.net/configreference/system.webserver/fastcgi/application#005 , the requestTimeout setting). Additionally, there's a timer tracking FastCGI request activity (activityTimeout, default 30 seconds, see the same page).
If the php-cgi instance is killed while a script is executing, it's highly probable that Wincache's cross-process memory will get corrupted.
If Wincache's cross-process memory gets corrupted, all PHP instances in the appPool must be terminated *simultaneously* to recover.
So, here's the ask:
For folks who are seeing event log entries where php-cgi.exe / Wincache crashed, could you check your HTTP W3C log files (%systemDrive%\inetpub\logs\LogFiles\<site>\u_ex*.log) and see if there was a 500 status message on a PHP request *before* the crash?
I'm particularly interested in the win32 status codes that on the 500 messages that happened before the 500 associated with the crash.
I'm looking into improving the diagnosability of when the FastCGI handler terminates an instance, so we can help customers see if the Wincache crashes are due to avoidable timeouts. Additionally, I'm looking into ways that Wincache can more gracefully recover from these kinds of corruptions.
Thank you!
--E.
Hello,
I just installed WinCache to improve performance in combination with Symfony2 on Windows 8.1. But the main feature to improve performance (The file function rerouting) is not working :(.
My php.ini looks like this:
[wincache] wincache.fcenabled=1 wincache.fcachesize=64 wincache.ocenabled=0 wincache.ucenabled=0 wincache.rerouteini="reroute.ini"
And my reroute.ini (in the same directory) looks like this:
[FunctionRerouteList] file_exists=wincache_file_exists file_get_contents:2=wincache_file_get_contents filesize=wincache_filesize readfile:2=wincache_readfile is_readable=wincache_is_readable is_writable=wincache_is_writable is_writeable=wincache_is_writable is_file=wincache_is_file is_dir=wincache_is_dir realpath=wincache_realpath
There seems to be no entry at all either for the rerouting in my phpinfo().
This is what it says about wincache (sorry for the lousy formatting):
wincache Opcode cache disabled File cache enabled Version 1.3.5.0 Owner iisphp@microsoft.com Build Date Jul 30 2013 09:33:20 Directive Local Value Master Value wincache.apppoolid no value no value wincache.chkinterval 30 30 wincache.debuglevel 0 0 wincache.enablecli Off Off wincache.fcachesize 64 64 wincache.fcenabled On On wincache.fcenabledfilter no value no value wincache.fcndetect On On wincache.filecount 4096 4096 wincache.ignorelist no value no value wincache.internedsize 4 4 wincache.localheap 0 0 wincache.maxfilesize 256 256 wincache.namesalt no value no value wincache.ocachesize 96 96 wincache.ocenabled Off Off wincache.ocenabledfilter no value no value wincache.scachesize 8 8 wincache.ttlmax 1200 1200 wincache.ucachesize 8 8 wincache.ucenabled Off Off
Does anyone know how to make it work?
Thanks!
Just noticed the 1.3.6 release on SourceForge. After download and extracting it (not happy that the msi insists on PHPPATH to be set) I've found the reroute.ini file. Does that mean that funtionality has been restored and is now available? What's different in the 1.3.6 version? Does it fix any bugs/crashes? Or is it just "experimental" to test 5.6RC compatibility?
at php you can:"
session_set_cookie_params(0, '/', '%.example.com%');
session_start();
"
the sessions info will be shared at whole *.example.com domains.
but not when you use session.save_handler= wincache
Hi,
since PHP 5.6 is out, can we use the latest version of Wincache (1.3.6.1) for it, or are any changes required? Has anyone tested?
Cheers,
Mike
The IIS team has published the release version of WinCache Extension 1.3.6.1 for PHP 5.6. This is the latest stable and production ready version of the extension for PHP 5.6.
Installation using the Web Platform Installer is easiest, as it will automatically place the extension binary into proper location and will update the PHP configuration to enable the extension. Also, if you have the previous version of the extension installed, then Web PI will upgrade it. If you install any PHP 5.6 application by using Web PI, the WinCache Extension 1.3.6.1 for PHP will be offered as an optional component.
If you install the extension manually, then follow the instructions at Installing/Configuring WinCache for PHP.
Notes
zend_extension=php_opcache.dll [opcache] opcache.enable=1
Thanks!
The IIS team thanks all of you who have installed and tried early releases of the WinCache extension and provided us with feedback, bug reports and feature suggestions through theWindows Cache Extension for PHP Forum. Your involvement throughout the release process has been very valuable to us and really helped us make this a great release!
We are not currently using Wincache, but thought I would mention this. For some configurations of IIS, Zend Opcache is unusable (it is for us) due to a memory addressing / ASLR issue on Windows:
Event ID 487 from source Zend Opcache
Unable to reattach to base address
Attempt to access invalid address.
https://github.com/zendtech/ZendOptimizerPlus/issues/167
We have not been able to use Zend Opcache for some time now and probably won't until either PHP is stable and fully supported in 64 bit or someone solves this problem in 32 bit (I'm paraphrasing notes from the Github issue.)
I think it would be premature for MS to remove Opcache from Wincache until that issue is resolved.
We have php 5.4 and 5.3 wincache enabled and with opcode caching enabled we have lots of fastcgi errors in our logs:
Faulting application php-cgi.exe, version 5.4.13.0, time stamp 0x514274c8, faulting module unknown, version 0.0.0.0, time stamp 0x00000000, exception code 0xc0000005, fault offset 0x0000270f, process id 0x1654c, application start time 0x01cfe75a8e482780.
Yesterday i have tried the latest 1.3.6.1 wincache but same results. When disabling opcode cache no critical error at all.
Due to this errors the relyability monitor index is about 1. Thats bad.
Anyone?
FYI--
As an attempt to improve stability of Wincache when there are large numbers of php-cgi.exe instances sharing a single cross-process shared memory segment, I've created an experimental version, adding the ability to disable the Shared Reader/Writer (SRW) locking mechanism. This should prevent the problem of deadlocking all php-cgi.exe instances for an Application Pool if the FastCgi manager decides to forcibly terminate a single php-cgi.exe instance.
In the experimental version of WinCache, I've added a setting (wincache.srwlocks) to disable the SRW locks. The default for this setting is '1', meaning SRW locks are enabled. This is to ensure the default matches the current behavior of the released version. To disable SRW locks, set wincache.srwlocks=0 in the php.ini file.
Fair Warning #1: If you turn off SRW locks, there will be a slight loss in performance. In the worst case, it can be as much as 15%. So, disabling WinCache's SRW locks should only be done by customers who are seeing deadlocks in production. With that said, this just means you'll only see a 1.8x to 2.25x performance improvement with WinCache, as opposed to 2x to 2.5x improvement.
Fair Warning #2: This is an experimental version, and NOT an official release. Customers should perform extensive testing to verify stability before considering deployment to any production environment.
For anyone who picks up this version and tries it out with wincache.srwlocks=0, please let me know if this fixes your deadlocking issue!
Thx!
--E.
My application's perfromance degrades after a few hours of usage, effectively doubling execution time.
Problem goes away by reseting IIS.
I have the feeling that this might be related to degrading wincache performance. I have started to collect dumps prior to degradation, will have to wait for degradation to happen and get dumps to compare. This forces me to leave XDebug enabled in production site... not a nice idea it has a negative impact on performance.
I rememeber a similar issue when wincache user_cache filled up and only an IIS restart will solve the problem, so I setup a watchdog that resets user_cache when it gets to a 90% fill threshold.
The only persistent thing in IIS that is PHP related is Wincache or Sessions (I'm actually ussing wincache session management).
I'll see if the dumps effectively point to wincache related operations and post the results here.
Just a quick note about something I've discovered through debugging a recent WinCache issue:
If you change the wincache.scachesize value, you MUST shutdown all php-cgi.exe instances and manually delete the wincache_session_*.tmp file.
The wincache_session_*.tmp file will in the directory specified by seesion.save_path in the php.ini file.
An example session file name would look like: wincache_session_1_565779.tmp
If you don't delete this file, you will run into corruption in cross-process shared memory segments for the WinCache session handler. These will show up as 500 errors from your IIS server.
Thx!
--E.
I suggest using DebugDiag for collecting all crashes for process php-cgi.exe.
DebugDiag: http://www.microsoft.com/en-us/download/details.aspx?id=40336
Pro Tip:Dumps with full heap are more useful for WinCache crashes. On the "Advanced Configuration (Optional)" dialog, click on the "PageHeap Flags..." button. Make sure "Enable Full PageHeap" radio button is selected on the "Configure PageHeap Flags" dialog.
Alternately, here are a couple of blog posts about how to collect crash dumps.
Steps to Catch a Simple “Crash Dump” of a Crashing Process
Collecting User-Mode Dumps
From <http://msdn.microsoft.com/en-us/library/bb787181.aspx>
Thx!
--E.
Hello,
I have the application pool that uses wincache. Once in 2-3 days it freezes. I can see all (6) php processes and they load CPU at 0% but the site pages cannot be opened. All requests are unfinished. I tried 5.3.8 and couplle of 5.2.x php versions with different wincache dll's. But the problem keeps. When it happens there are no errors in php log.
Where should I dig to find the reason?
Thank you i advance,
Yael