|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #58986 Get rid of local cache
Submitted: 2009-12-13 19:47 UTC Modified: 2009-12-21 12:33 UTC
From: Assigned: DonRaman (profile)
Status: Closed Package: WinCache (PECL)
PHP Version: 5.2.11 OS: Windows
Private report: No CVE-ID: None
 [2009-12-13 19:47 UTC]
Creating a local cache seems an extra overhead and the code should try getting rid of this. I can see couple of problem related to this creation of local cache:
1. WINCACHE.PHP not showing consistent result. When this page gets refreshed, the rendering is done by more than one PHP request. There is one for the tables/text and depending on number of images to be drawn there can be more PHP requests. If these request go to different php-cgi.exe and anyone has local cache, the result of the page is not consistent with the tables. The same can happen when table creation/text request goes to php-cgi.exe having local cache and images gets served from php-cgi.exe serving global cache.
2. There is too much of complexity in the code because of this. The code does complex locking to ensure that local cache is indeed local.

Reproduce code:
This is a feature change request. I do not have any code to reproing this.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2009-12-14 00:14 UTC] don dot raman at microsoft dot com
I have got rid of local cache. I did below testing:

1. Ran wordpress/joomla/moodle/phpmyadmin/drupal/gallery with the new binaries. It seems to work fine. However this is no big deal as we need to test for a situation where local cache was getting created.
2. In order to create local cache, I tweaked the code where first time cache creation will fail always. Did the above test again and it works. I have now some confidence in the patch.
3. I also coded a scenario where the initialization fails at all the time and ensured that PHP applications are working fine.
4. I did test WINCACHE.PHP to ensure that PHP functions exposed by WINCACHE is also behaving properly. So in case 3 I can see all the cache being empty as I forced the initialization to fail every time. In case 3 it was empty for the first time and later got filled. Again a correct behaviour.

There might be a situation where because of shared memory not being mapped to the same address (in which case previously we were creating local cache), with the fix we simply return. Unless the cache gets re-initialized again and if request for WINCACHE.PHP comes to this php-cgi.exe, it may show zero statistics. But I am not sure if we can do anything about this. However I have minimized this by calling cache_initialize for open_stream as well as compile functions for the case where file named in winache.php. However this is just a mitigation. But good thing is that whenever we enter this situation the picture will be empty which can be documented easily.

Some more testing with debug output statements. Observation:
1. for wincache.php which creates minimum 3 php-cgi process, observed that cache fails at times with code 205 or 5003.
2. I didn't understand 205 much
3. But there were also times when cache was created correctly (all of them).

Patch can be found at

This patch just gets rid of creation of local cache not the code at various places which checks for this.

Please review this.
 [2009-12-14 00:49 UTC] don dot raman at microsoft dot com
The reason for getting 205 is that OpenFileMapping is returning the error code 5 (Access Denied).
 [2009-12-14 07:44 UTC] ksingla at microsoft dot com
Opcode cache needs to be mapped at the same address so that opcode generated by one process can be used by another process without deep copy. A new process cannot always map memory at the same address and when a process fails to map at the same address, a local cache is used to make sure request processing doesn't involve opcode generation every time. We should not remove local cache.
 [2009-12-14 17:03 UTC] don dot raman at microsoft dot com
It seems like getting rid of local cache completely will take a lot of time and there is a chance that this may degrade WINCACHE overall performance. By getting rid of local cache I mean without having few PHP CGI executable not serving from cache at all which what the patch does currently. This is because WINCACHE byte code shared memory stores Zend pointers and hence mapping shared memory to a different address is not a possible solution for byte code caching.

To the least let's implement a WINCACHE directive which will disable local cache and can be useful for troubleshooting.
 [2009-12-14 19:46 UTC] don dot raman at microsoft dot com
Assigning it to myself.
 [2009-12-21 12:33 UTC] don dot raman at microsoft dot com
This bug has been fixed in SVN.

In case this was a documentation problem, the fix will show up at the
end of next Sunday (CET) on

In case this was a website problem, the change will show
up on the website in short time.
Thank you for the report, and for helping us make PECL better.

I have created a branch named futures and the fix for the crash is committed there. To view the changes look at:

At some point of time, this should be merged to mainline release.
 [2009-12-21 12:44 UTC] don dot raman at microsoft dot com
For completeness sake.

After doing more research, it seems getting rid of local byte code cache is not possible. So a new WINCACHE INI directive has been introduced which is named NOLOCALCACHE. This directive controls if the local cache will be created or not if MapViewOfFileEx fails to map the shared memory at the same address. The default value for this directive is '0' which means local cache will be created by default. However setting it to '1' will ensure that no local cache is created. In this cache byte code caching will be disabled completely for that particular php-cgi.exe process and will be passed on to Zend core for handling the request. File Cache will still continue working though.

This is at this time intended for troubleshooting purpose only and this directive should be used for the same purpose.
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Tue Jun 25 17:01:26 2019 UTC