logo
Apache Lounge
Webmasters

 

About Forum Index Downloads Search Register Log in RSS X


Keep Server Online

If you find the Apache Lounge, the downloads and overall help useful, please express your satisfaction with a donation.

or

Bitcoin

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.
Post new topic   Forum Index -> Other Software View previous topic :: View next topic
Reply to topic   Topic: PHP Caching extensions accessing shared memory Page Previous  1, 2, 3
Author
C0nw0nk



Joined: 07 Oct 2013
Posts: 241
Location: United Kingdom, London

PostPosted: Wed 11 Mar '15 16:04    Post subject: Reply with quote

Looks like they updated Wincache again, http://svn.php.net/viewvc/pecl/wincache/trunk/

Jan let me know when you have a latest into your build and i shall download Smile
Back to top
Jan-E



Joined: 09 Mar 2012
Posts: 1248
Location: Amsterdam, NL, EU

PostPosted: Wed 11 Mar '15 16:21    Post subject: Reply with quote

Which version shall I compile first?
Back to top
Jan-E



Joined: 09 Mar 2012
Posts: 1248
Location: Amsterdam, NL, EU

PostPosted: Wed 11 Mar '15 20:41    Post subject: Reply with quote

The 5.6.7.TC1 and 5.5.23RC1 builds now contain the updated wincache:
http://www.apachelounge.com/viewtopic.php?t=6156
Back to top
C0nw0nk



Joined: 07 Oct 2013
Posts: 241
Location: United Kingdom, London

PostPosted: Thu 12 Mar '15 1:04    Post subject: Reply with quote

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: 1248
Location: Amsterdam, NL, EU

PostPosted: Thu 12 Mar '15 2:01    Post subject: Reply with quote

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

PostPosted: Mon 30 Mar '15 20:12    Post subject: Reply with quote

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

PostPosted: Mon 30 Mar '15 20:21    Post subject: Reply with quote

C0nw0nk wrote:

I also use Wincache still as a usercache mechanism for my PHP application i just set the following for wincache.
Code:
wincache.namesalt=0x200000

http://php.net/manual/en/wincache.configuration.php#ini.wincache.namesalt
And it seems to be working well so far i will let you know how it goes.


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

PostPosted: Mon 30 Mar '15 21:50    Post subject: Reply with quote

C0nw0nk wrote:
Looks like they updated Wincache again, http://svn.php.net/viewvc/pecl/wincache/trunk/

Jan let me know when you have a latest into your build and i shall download Smile


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

PostPosted: Fri 03 Apr '15 13:38    Post subject: Reply with quote

Thanks for the explinations Drop_phone Smile 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: 1248
Location: Amsterdam, NL, EU

PostPosted: Fri 03 Apr '15 15:57    Post subject: Reply with quote

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

PostPosted: Tue 07 Apr '15 18:01    Post subject: Reply with quote

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

PostPosted: Wed 08 Apr '15 22:57    Post subject: Reply with quote

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: 1248
Location: Amsterdam, NL, EU

PostPosted: Mon 13 Apr '15 0:11    Post subject: Reply with quote

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

PostPosted: Sat 25 Apr '15 2:09    Post subject: Reply with quote

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: 1248
Location: Amsterdam, NL, EU

PostPosted: Fri 15 May '15 17:32    Post subject: Reply with quote

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

PostPosted: Wed 22 Jul '15 19:04    Post subject: Reply with quote

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

PostPosted: Wed 19 Aug '15 0:24    Post subject: Reply with quote

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: 1248
Location: Amsterdam, NL, EU

PostPosted: Thu 20 Aug '15 13:33    Post subject: Reply with quote

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


Reply to topic   Topic: PHP Caching extensions accessing shared memory View previous topic :: View next topic
Post new topic   Forum Index -> Other Software Page Previous  1, 2, 3