|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #57975 Support for FastCGI on IIS
Submitted: 2007-12-20 09:19 UTC Modified: 2014-02-28 12:46 UTC
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (100.0%)
From: php at iis-aid dot com Assigned: krakjoe (profile)
Status: Closed Package: APC (PECL)
PHP Version: Irrelevant OS: Windows
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: php at iis-aid dot com
New email:
PHP Version: OS:


 [2007-12-20 09:19 UTC] php at iis-aid dot com
As far as I am aware FastCGI support in APC requires all new PHP processes to be spawned as child processes of the first PHP processes launched by FastCGI. This is not valid when using PHP with FastCGI on IIS as all additional PHP processes are launched as child processes of the IIS process. Some of the detrimental effects this has are;

1) Memory is not shared between PHP processes.

2) As each PHP process stores precompiled scripts in their own memory space, there is potential for a single PHP script to exist in several different caches as PHP processes are not tied to serving all requests for individual scripts. 

3) Memory consumption potential is equal to apc.shm_size multiplied by the number of PHP processes running. 

4) When new PHP processes are launched as load increases they do not benefit from existing cached scripts which can lead to performance issues.

5) When PHP processes are recycled by FastCGI the APC cache tied to this process is lost.

Reproduce code:
1) Using Windows 2003 operating system install IIS and Microsoft's FastCGI handler (

2) Configure FastCGI for use with PHP setting MaxInstances to greater than 1 and MaxRequests to a low number (e.g. 10) to accentuate recycling issue (

3) Configure PHP to use APC extension.

4) Access PHP script while monitoring apc.php to view status of APC cache.


Expected result:
APC to share memory between PHP processes.

Actual result:
APC does not share memory between PHP processes which not only leads to loaded servers, but also potentially cause associated issues as outlined in description field.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2008-03-29 01:57 UTC]
Just FYI, we have nobody working on APC that does anything on Windows.  You might get lucky and an eventual UNIX fastcgi-related fix will help you,
 [2008-07-06 06:34 UTC] php at iis-aid dot com
Thanks for the reply Rasmus. Thomas Deml who is the Senior Program Manager for IIS at Microsoft said they were working on this issue with the APC owners. I assumed this meant they had contacted yourself, Daniel or George being the leads for APC. Is this not the case?

Statement from Thomas Deml here;
 [2008-07-06 09:37 UTC]
I haven't heard anything.  The current active APC developers are myself, Gopal and Brian Shire.  If they have some change they want to make, they need to contact one of us, or post to the apc-devel mailing list.
 [2014-02-28 12:46 UTC]
-Status: Open +Status: Closed -Assigned To: +Assigned To: krakjoe
 [2014-02-28 12:46 UTC]
Closing this bug for several reasons:
 APC is no longer the primary means of caching opcodes.
 This bug is extremely old, no feedback has been given here, a sensible assumption is that if a patch were made ready it was dealt with elsewhere and merged, or not.

Thanks for helping to make PHP better :)
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Mon May 23 23:05:47 2022 UTC