Quantcast
Channel: Windows Cache Extension for PHP
Viewing all 197 articles
Browse latest View live

64-bit version for PHP 5.5

$
0
0

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 


WinCache Functions Reroutes as a standalone extension ?

$
0
0

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

symbolic link issue, fails to detect changed files

$
0
0

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.

Faulting application php-cgi.exe, version 5.2.11.11, time stamp 0x4ab13019

$
0
0
<div dir=ltr id=result_box>Faulting application php-cgi.exe, version 5.2.11.11, time stamp 0x4ab13019, faulting module php_wincache.dll, version 1.0.1012.0, time stamp 0x4ad39bd7, exception code 0xc0000005, fault offset 0x0000294d, process ID 0x5ec, application startup Time 0x01ca527533907c77.</div>

错误应用程序 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>

User Cache TTL Not Working

$
0
0

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??

Locking Up / Not Responding / 500 Error

$
0
0

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.

php_wincache.dll 1.3.5 fault

$
0
0

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>
 

HTTP 500 errors and Wincache crashes: Request for Info

$
0
0

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.


Function reroute not working

$
0
0

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!

Wincache 1.3.6

$
0
0

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?

session.save_handler = wincache don't share correctly

$
0
0

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

PHP 5.6

$
0
0

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

Wincache 1.3.6 release on SourceForge

$
0
0

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

  • In PHP 5.5 and later, the Zend Opcache extension is now in the core PHP product, although the extension is not loaded by default.  To load the Zend Opcache extension, ensure the following line is included in the php.ini file:
zend_extension=php_opcache.dll
[opcache]
opcache.enable=1
  • Since the Zend Opcache extension is now in the core PHP product, the WinCache opcode cache is disabled by default.  The opcode cache portion of WinCache is now deprecated, and will be removed in a future release of the WinCache extension.
  • The extension can only be used with non-thread-safe builds of PHP
  • The extension can only be used when IIS is configured to run PHP via FastCGI
  • The WinCache Extension 1.3.6.1 for PHP 5.6 can only be used with the x86 VC11 build of PHP 5.6.

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!

Removal Of Opcache Feature / Zend Opcache Failure

$
0
0

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.

fastcgi error event 1000 with wincache opcode cache enabled

$
0
0

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?


Experimental: Disabling Shared Reader/Writer Locks in WinCache

$
0
0

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.

PHP 5.6: http://sourceforge.net/projects/wincache/files/development/wincache-1.3.6.2-dev-5.6-nts-vc11-x86.exe/download

PHP 5.5: http://sourceforge.net/projects/wincache/files/development/wincache-1.3.6.2-dev-5.5-nts-vc11-x86.exe/download

PHP 5.4: http://sourceforge.net/projects/wincache/files/development/wincache-1.3.6.2-dev-5.4-nts-vc9-x86.exe/download

PHP 5.3: http://sourceforge.net/projects/wincache/files/development/wincache-1.3.6.2-dev-5.3-nts-vc9-x86.exe/download

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.

Degrading performance

$
0
0

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.

Word of caution for people who change the wincache.scachesize

$
0
0

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.

How to collect a crash dump

$
0
0

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

 

From <http://blogs.msdn.com/b/chaun/archive/2013/11/12/steps-to-catch-a-simple-crash-dump-of-a-crashing-process.aspx>

 

Collecting User-Mode Dumps

 

From <http://msdn.microsoft.com/en-us/library/bb787181.aspx>

Thx!

    --E.

wincache application pool freezes

$
0
0

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

Viewing all 197 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>