locked
Opcode memory management incompatibility with MS FastCGI RRS feed

  • Question

  • User2093557029 posted

    A while ago I attempted to configure the xCache opcode module for PHP with FastCGI to get a decent performance boost. However after discussions with the xCache devs it appears that Opcode PHP caches (open source ones anyway) are never going to be a really viable option with FastCGI on IIS because of the way xCache (and APC apparently) share the allocated memory between all the php-cgi.exe processes. The catch is that these caches only share the memory when additional php-cgi.exe processes are created as child processes of the original php-cgi.exe processs, which is not valid under IIS as all php-cgi.exe processes are created as children of the W3WP.exe process. The result this has is that the cache is cleared everytime a new PHP process is launched and the memory is not shared between them. Short of patching these Opcode caches does anyone have any idea of how (or if) this can be worked around?

    Thursday, December 13, 2007 11:23 AM

Answers

  • User1356161706 posted

    Brashquido,

    This problem requires changes in the APC. We are working on this issue with the APC owners.  

    <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p> </o:p>

    You can get some short term relief by setting InstanceMaxRequests to a very large number (and configuring the PHP_FCGI_MAX_REQUESTS server variable to a matching number.)  This will cause the php-cgi.exe processes to live a long time.  We are testing routinely with 10,000 requests per process lifetime without issues, and we have also tested to 100,000 requests per lifetime and not seen any instability in PHP itself.  As long as your application code doesn’t introduce problems, this should work for you.

     

    Hope this helps<o:p></o:p>

     

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Wednesday, December 19, 2007 12:17 PM

All replies

  • User1356161706 posted

    Brashquido,

    This problem requires changes in the APC. We are working on this issue with the APC owners.  

    <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p> </o:p>

    You can get some short term relief by setting InstanceMaxRequests to a very large number (and configuring the PHP_FCGI_MAX_REQUESTS server variable to a matching number.)  This will cause the php-cgi.exe processes to live a long time.  We are testing routinely with 10,000 requests per process lifetime without issues, and we have also tested to 100,000 requests per lifetime and not seen any instability in PHP itself.  As long as your application code doesn’t introduce problems, this should work for you.

     

    Hope this helps<o:p></o:p>

     

    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Wednesday, December 19, 2007 12:17 PM
  • User2093557029 posted

    Thanks for the reply Thomas, I thought as much. Very exciting news that you've been speaking with the APC devs though. Think I'll stick with ISAPI for the minute as I'm not having any issues with the extensions I'm using and APC is seeming quite stable.

     
     

    Wednesday, December 19, 2007 5:56 PM
  • User2093557029 posted

    For anybody else hitting this issue I've created a bug report against the APC project here;

    http://pecl.php.net/bugs/bug.php?id=12735

    Thursday, December 20, 2007 9:21 AM
  • User2093557029 posted

    This is also explained a bit better than what I have here in the xCache FAQ; 

    http://xcache.lighttpd.net/wiki/Faq#Iseejumpyhitsinadminpage

    Thursday, December 20, 2007 9:23 AM
  • User1466771427 posted

     Really glad to hear you're working with APC devs to resolve this issue.  Any thoughts on when the it might be resolved?  Also, thanks for the tip on a work around of sorts ... I'm looking forward to giving it a whirl.

    Saturday, January 19, 2008 9:57 AM
  • User1466771427 posted

    I <strike>updated apc to the latest build from PECL4WIN</strike> and made used the fastcgi config changes above and I haven't seen a 500 error so far.  Thanks for the tip! 

     

    Update: Doh ... APC wasn't loading so I had to revert.

    Tuesday, January 22, 2008 11:59 AM
  • User-95264152 posted

    I am wondering if there is any updates to this?

    Support for APC, Xcache or eAcclerator working properly in IIS7 using FastCGI.

    Wednesday, July 9, 2008 10:32 PM
  • User2093557029 posted

    Nothing as yet, at least not for APC. In the bug report I linked to above Rasmus (guy who created PHP and is a lead dev for APC) said they have not heard anything about implementing MS FastCGI support in APC. What's more there are no devs working on APC who used Windows/IIS, so it MS FastCGI support is not going to happen unless the IIS team are able to hand the required code to the APC dev team on a silver platter... 

    Saturday, July 12, 2008 12:58 PM
  • User-2140010589 posted

    The problem with Memory management in the Opcode cachers isn't limited to IIS. Their incompatability is related to FastCGI in general, not IIS in particular. The issue is they allocate memory for every PHP process, not PHP as a whole. The problem is exacerbated by IIS because it's FastCGI implementation spawns no children.

    However, the workaround on Apache and Lighttpd that makes APC, Eaccelerator "work" with FastCGI and I put work in quotes because it's still a hack IMO is to reduce the number of PHP processes to 1 or 2 then create a ton of children.

    The problem is, this causes one bad child to bring down all of the other children, thus reducing alot of the benefits of FastCGI in the first place which is process isolation.

    I just wanted to be clear that this issue should be addressed as an issue with the Opcode cachers as a whole on all platforms. IIS just makes their problem more obvious.

    -Stephen

    Thursday, July 31, 2008 3:38 PM
  • User-1444643443 posted

     I also have been trying for a week to get eaccelerator to work with fastcgi php.

     No luck. I cant find any how-tos on installing EA on thread safe php as fastcgi. I didn't even know possible.

    Monday, January 12, 2009 8:12 AM
  • User-95264152 posted

     Has there been any updates or progress in getting APC working with FastCGI on IIS?

    Sunday, January 17, 2010 7:25 AM
  • User2093557029 posted
    I'd suggest you look at WinCache instead.
    Monday, January 18, 2010 3:22 AM
  • User-95264152 posted

     well look at that! I havn't really touched my servers since the summer, so I hadn't heard about this WinCache. Looks very interesting, I will try it out tommorow.

    Thanks for letting me know!

    Monday, January 18, 2010 5:48 AM