Keep Server Online
If you find the Apache Lounge, the downloads and overall help useful, please express your satisfaction with a donation.
or
A donation makes a contribution towards the costs, the time and effort that's going in this site and building.
Thank You! Steffen
Your donations will help to keep this site alive and well, and continuing building binaries. Apache Lounge is not sponsored.
| |
|
Topic: PHP Caching extensions accessing shared memory |
Page Previous 1, 2, 3 |
Author |
|
C0nw0nk
Joined: 07 Oct 2013 Posts: 241 Location: United Kingdom, London
|
|
Back to top |
|
Jan-E
Joined: 09 Mar 2012 Posts: 1266 Location: Amsterdam, NL, EU
|
Posted: Wed 11 Mar '15 16:21 Post subject: |
|
|
Which version shall I compile first? |
|
Back to top |
|
Jan-E
Joined: 09 Mar 2012 Posts: 1266 Location: Amsterdam, NL, EU
|
|
Back to top |
|
C0nw0nk
Joined: 07 Oct 2013 Posts: 241 Location: United Kingdom, London
|
Posted: Thu 12 Mar '15 1:04 Post subject: |
|
|
Thanks Jan Will download shortly sorry for the late reply i only run PHP 5.6 so latest.
Looks like they seem to be realy ontop of wincache recently they updated it again 2 hours ago. I wounder if they are aware that the OPCode cache in wincache is not sharing its memory. But yet all the other Resolve Path cache, Usercache, Session cache and File cache do.
How do you tell the developer to check out the OPCode cache for sharing its memory so they can fix that.
For me when ever a PHP process terminates the OPCache seems to be dropped and all my processes are running seperate opcaches but all sharing the Resolve Path cache, Usercache, Session cache and File cache because i set a apppoolid.
So right now my current fix is still using Zend OPCache instead of Wincaches OPCache. |
|
Back to top |
|
Jan-E
Joined: 09 Mar 2012 Posts: 1266 Location: Amsterdam, NL, EU
|
Posted: Thu 12 Mar '15 2:01 Post subject: |
|
|
You can contact the developers through the forum:
http://forums.iis.net/1164.aspx
DropPhone == Eric Stenson (lead) == ericsten |
|
Back to top |
|
drop_phone

Joined: 30 Mar 2015 Posts: 8 Location: USA, Redmond
|
Posted: Mon 30 Mar '15 20:12 Post subject: |
|
|
C0nw0nk wrote: | I wounder if they are aware that the OPCode cache in wincache is not sharing its memory. |
WinCache most certainly *does* share its memory.
There appears to be some confusion about how WinCache works under-the-covers, and now that I've found this forum, let me try and set the record straight.
For all the caches except the opcode cache, the base address of the segment for the shared memory doesn't matter. Two different processes can map the same cache at different base addresses, and things just work because everything is done as relative offset addressing.
However, the opcode cache is different: All processes sharing the opcode cache MUST map the shared memory segment at the same address. Before WinCache 1.3.7.4, this was determined by the first process to load WinCache. Wherever it alloc'd, that was the base address. And, if a subsequent process couldn't map the segment at that base address, it would "fall back" to a local memory segment for the opcode cache. While this gave the behavior that OP initially noticed, it did provide for "survivability" in the face of random startup behaviors.
And, as it turns out, even subtle changes in the order of allocations could lead subsequent process instances would often times not be able to map at the same address. Different modules loading before WinCache would alter their allocation patterns, and it would make it impossible to map the contiguous segment at the same address as the first process.
In 1.3.7.4 (actually, a little earlier than that), I altered the algorithm to select the base address for a memory segment. It now figures out the top of allocate-able memory, and then probes backwards until it can find a segment which is large enough to accommodate the segment. This seems to behave a bit better, but it's still not perfect. When spawning 50+ php-cgi.exe's at a time, a fraction will still fall back to local opcode cache.
Now, for my next subject: wincache.apppoolid is the IIS Application Pool name. If WinCache is not running under IIS, this setting is not set. And, as others have noticed, WinCache won't use shared memory unless this value is set. This is because the application pool is used to create separate named memory segments. You don't want to share the opcodes or files or user cache or session data between application pools, since that's the unit of isolation on an IIS box. You can fake this out by setting the apppoolid on a non-IIS box, and that should be fine.
Finally, I'd like to talk about the recent change I've made to move the shared memory segments out of the system page file. This is primarily beneficial to folks who have more than a few dozen application pools on a server. This is because WinCache creates the shared memory segments in the System Page File, and if everyone specifies a massive size for their caches, this can quickly deplete the System Page File, and lead to startup errors.
In WinCache 1.3.7.4, if you are (a) running on IIS, and (b) set the wincache.filemapdir http://php.net/manual/en/wincache.configuration.php#ini.wincache.filemapdir, then WinCache will create the shared memory segments in separate files. As part of this, to ensure the safety and protection of the data in those files, it will ACL those files such that only the system, admin and IIS Application Pool will be able to access them. If WinCache can't ACL the file, it won't use it, and will fall back to the safety of the System Page File. This means that on Apache (which doesn't have a separate account for the application pool in LSASS), this functionality won't work. You will, however, continue to share memory via the System Page File.
If you have further questions, please follow up on the PHP WinCache Forum on IIS.net http://forums.iis.net/1164.aspx
Thank you!
--E. |
|
Back to top |
|
drop_phone

Joined: 30 Mar 2015 Posts: 8 Location: USA, Redmond
|
Posted: Mon 30 Mar '15 20:21 Post subject: |
|
|
I have to correct this: the namesalt is an additional 8 char name that is used to create separate named objects. This is necessary if you are using two different WinCache versions (say for PHP 5.4 and PHP 5.5) in the same application pool. If you don't have a different namesalt between the two versions, they will attempt to create the same shared memory map name, and bad, bad things will happen. Primarily, the opcode/zval structs are different between PHP versions, and having PHP 5.4 try to execute an zend_oparray compiled by PHP 5.5 will Do Bad Things(tm).
The value is not an address. It's a name (up to 8 characters).
Thx!
--E. |
|
Back to top |
|
drop_phone

Joined: 30 Mar 2015 Posts: 8 Location: USA, Redmond
|
Posted: Mon 30 Mar '15 21:50 Post subject: |
|
|
Just so you know: I build and release NTS x86 bits out to SourceForge whenever I have a tested version of the code. I put it in the "Developer" folder, meaning that it has gone through run-tests.php (developer unit tests), and it nominally works "on my machine", but has not been through complete release-level testing.
Note that WinCache is not supported for x64, nor TS versions. In fact, I don't think that WinCache even builds for TS flavors.
Thx!
--E. |
|
Back to top |
|
C0nw0nk
Joined: 07 Oct 2013 Posts: 241 Location: United Kingdom, London
|
Posted: Fri 03 Apr '15 13:38 Post subject: |
|
|
Thanks for the explinations Drop_phone I do not use a namesalt anymore since i run a single latest php build now instead of multiple. So all i use is the App Pool ID so it shares its memory.
And the Wincache 64Bit versions i use are compiled by Jan-E and they work just fine. Aswell as i only run NTS PHP i will never use a Threaded PHP again after how horrible it was.
Who compiles the Wincache Versions found on the PHP site then ? http://windows.php.net/downloads/pecl/releases/wincache/ |
|
Back to top |
|
Jan-E
Joined: 09 Mar 2012 Posts: 1266 Location: Amsterdam, NL, EU
|
Posted: Fri 03 Apr '15 15:57 Post subject: |
|
|
The builds at windows.php.net are more or less automatic builds at every release. The server is managed by colleagues of drop_phone at Microsoft (Anatol Belski, Pierre Joye and others). See http://windows.php.net/team/
As far as I know the 64-bit builds work fine. In fact it is even possible in those builds to increase the max sizes to 2046 (2048-2) MB. I once experimented with that. |
|
Back to top |
|
C0nw0nk
Joined: 07 Oct 2013 Posts: 241 Location: United Kingdom, London
|
Posted: Tue 07 Apr '15 18:01 Post subject: |
|
|
Jan-E wrote: | The builds at windows.php.net are more or less automatic builds at every release. The server is managed by colleagues of drop_phone at Microsoft (Anatol Belski, Pierre Joye and others). See http://windows.php.net/team/
As far as I know the 64-bit builds work fine. In fact it is even possible in those builds to increase the max sizes to 2046 (2048-2) MB. I once experimented with that. |
Funny you mention that because i did that before but was unsure if it was working so i reduced everything back down to the defaults and max values as written on the docs.
http://php.net/manual/en/wincache.configuration.php |
|
Back to top |
|
drop_phone

Joined: 30 Mar 2015 Posts: 8 Location: USA, Redmond
|
Posted: Wed 08 Apr '15 22:57 Post subject: |
|
|
Jan-E wrote: |
As far as I know the 64-bit builds work fine. |
Look in wincache_fcache.c, read_file_content(...). There's a naked cast of a pointer to DWORD. The minute you have a file larger than 4GB, you're hosed. This is true for x86 and x64, I know, but it's something that really should get fixed before WinCache can call itself truly x64 compliant.
Jan-E wrote: |
In fact it is even possible in those builds to increase the max sizes to 2046 (2048-2) MB. I once experimented with that. |
Unless you're modifying the #defines that WinCache uses to range-check the configuration settings, I'm not sure how changing the max size would work. Which settings are you talking about, specifically?
Thx!
--E. |
|
Back to top |
|
Jan-E
Joined: 09 Mar 2012 Posts: 1266 Location: Amsterdam, NL, EU
|
Posted: Mon 13 Apr '15 0:11 Post subject: |
|
|
drop_phone wrote: | Jan-E wrote: | As far as I know the 64-bit builds work fine. | Look in wincache_fcache.c, read_file_content(...). There's a naked cast of a pointer to DWORD. The minute you have a file larger than 4GB, you're hosed. This is true for x86 and x64, I know, but it's something that really should get fixed before WinCache can call itself truly x64 compliant.
|
If it is the same for both, there is no reason not to use Wincache-x64 if you (for some reason or another) prefer to use 64-bits PHP. And, besides that, what would be the point to use Wincache for a 4GB file? It does not fit in any of the three caches anyway.
drop_phone wrote: | Jan-E wrote: | In fact it is even possible in those builds to increase the max sizes to 2046 (2048-2) MB. I once experimented with that. | Unless you're modifying the #defines that WinCache uses to range-check the configuration settings, I'm not sure how changing the max size would work. Which settings are you talking about, specifically? |
I changed the defines to see how far I could get. Result: every of the three caches could be upgraded to 2046MB. |
|
Back to top |
|
C0nw0nk
Joined: 07 Oct 2013 Posts: 241 Location: United Kingdom, London
|
Posted: Sat 25 Apr '15 2:09 Post subject: |
|
|
I am curious and have a question for drop_phone (or anyone who can answer it realy) with wincache.apppoolid is there a max or min length like with the namesalt ?
Because i keep my name salt's to numbers per site. This way i know i do not exceed the 8 character limit.
for example :
Code: | domain.com | wincache.namesalt=1
domain2.com | wincache.namesalt=2 |
And so on and so forth.
But with my apppoolid's i currently do the following.
Code: | domain.com | wincache.apppoolid=DOMAIN
domain2.com | wincache.apppoolid=DOMAIN2 |
Is this good or bad am i doing the right or wrong thing by configuring wincache per site this way. |
|
Back to top |
|
Jan-E
Joined: 09 Mar 2012 Posts: 1266 Location: Amsterdam, NL, EU
|
Posted: Fri 15 May '15 17:32 Post subject: |
|
|
Found in the news file op PHP7
https://github.com/php/php-src/blob/master/NEWS#L144
Opcache:
. Added experimental (disabled by default) file based opcode cache. (Dmitry, Laruence, Anatol)
I did not look further what they want to achieve. |
|
Back to top |
|
drop_phone

Joined: 30 Mar 2015 Posts: 8 Location: USA, Redmond
|
Posted: Wed 22 Jul '15 19:04 Post subject: |
|
|
C0nw0nk wrote: | So where does it store the memory pool now if not in our paging file |
In the wincache.filemapdir.
Note that if you specify wincache as your session.save_handler, the backing file for the session shared memory will still be in the session.save_path directory.
Thx!
--E. |
|
Back to top |
|
drop_phone

Joined: 30 Mar 2015 Posts: 8 Location: USA, Redmond
|
Posted: Wed 19 Aug '15 0:24 Post subject: |
|
|
C0nw0nk wrote: | with wincache.apppoolid is there a max or min length like with the namesalt ?
|
Nope.
C0nw0nk wrote: |
But with my apppoolid's i currently do the following.
Code: | domain.com | wincache.apppoolid=DOMAIN
domain2.com | wincache.apppoolid=DOMAIN2 |
Is this good or bad am i doing the right or wrong thing by configuring wincache per site this way. |
The apppoolid setting is not really supposed to be used in production. It was added really for debugging during development, and kinda stayed around.
Having different apppoolid's really means you're creating different shared memory segments. So, instead of having one shared memory segment for all the URL's in a common IIS Application Pool, you're artificially creating more named memory segments. Since these are large, and will use the system page file, you can wind up exceeding quota rather quickly.
If you move all of the shared memory segments out of the system page file, that should avoid the quota problem.
Thx!
--E. |
|
Back to top |
|
Jan-E
Joined: 09 Mar 2012 Posts: 1266 Location: Amsterdam, NL, EU
|
Posted: Thu 20 Aug '15 13:33 Post subject: |
|
|
drop_phone wrote: | The apppoolid setting is not really supposed to be used in production. It was added really for debugging during development, and kinda stayed around. |
If you are using opcode caching and are using different PHP versions on the same machine, you really have to use a different apppoolid for each PHP version. |
|
Back to top |
|
|
|
|
|
|