I'm running IIS6 on Windows Server 2k3, and currently have PHP installed as a ISAPI module. We're about to upgrade our environment to PHP 5.3.0, and this made me wonder whether I should stick with the ISAPI module or if there was a reason the CGI would be a better fit.

We have one web server for our organization, and do not have to worry about security related to shared hosting; we have several web sites, but they all belong to us.

Is there an advantage to using one method over the other? Is one more secure? Is it simply a matter of preference?

EDIT: PHP 5.3.0 dropped support for ISAPI, so you do need to install it via FastCGI. From the PHP Migration Guide:

Support for the ISAPI module has been dropped. Use the improved FastCGI SAPI module instead.

  • 1
    I find it dissapointing that they've dropped ISAPI support. This means that if we ever want to migrate our web servers to a newer version of PHP (for the two or three PHP apps we run internally) I now have to learn (and thus maintain) ANOTHER intermediatory platform (namely FastCGI). Thus is the problem with Open Source/Free software, little thought is provided for those of us were "near enough" is "good enough" (i.e. internal software). – Mark Henderson Jul 27 '09 at 23:29
  • That is, in fact, EXACTLY what led to this question - I usually installed via ISAPI, and was upgrading to PHP 5.3.0. I didn't know that they had completely removed ISAPI support at the time, though. I don't see this as a problem in Free software, though - if I really didn't like that ISAPI support was dropped, I could write it back in. Developers in general have the ability to make decisions without regard to their users, not just open source developers. – Jacob Hume Jul 28 '09 at 14:37
  • Very inconsiderate of them to drop the recommended way to install PHP on IIS without a GIANT hint on the installer like "Looking for ISAPI? We dropped support and moved to FastCGI. Read about it here" – Carlos Lima May 31 '10 at 20:33
  • @JacobHume, Why do you say "Server 2k3" instead of simply "Server 2003"? – Pacerier Jun 25 '15 at 4:16
  • @Pacerier - It's just a colloquialism. From a pedantic point of view the question should be edited to make it more clear, at which point the name "Windows Server 2003" should probably be substituted, since that's the formal name of thae product (sans the "Edition" portion of the name-- but since this is an IIS question it applies to all editions of the product). I don't think it would add any particular value to the question to edit it. – Evan Anderson Jun 25 '15 at 8:35

The Non-Thread-Safe PHP CGI binary for Windows is supposed to give you maximum stability, compatibility and performance as:

  1. PHP was originally designed and optimized for multi-process environment
  2. Most of the extensions were created keeping that in mind
  3. There is no "waiting" that you see in multi-threaded environments

However, the performance and stability is susceptible when the CGI binary is used in multi-threaded environments such as IIS. Therefore most people have started using the relatively new FastCGI extension that is available for IIS 5.1/IIS 6.0 as a download and bundled with IIS7.

This guide explains how to install and configure PHP CGI with Microsoft's FastCGI extension.

The second option is to go for PHP ISAPI but be sure to (i) use Thread-Safe builds (ii) use stable and tested extensions -- the PHP ISAPI can otherwise crash and take down IIS as well. A side note is that tread-safety in PHP is like a hand-brake that is always engaged; some even say that it is a myth.

Update: PHP ISAPI is not shipped anymore so the question about ISAPI vs. CGI is not a question anymore. FastCGI is recommended.

  1. FastCGI support is built into modern versions of IIS, you just need to enable it.
  2. PHP installer presents the option of installing PHP with FastCGI.
  3. For people who want to perform ZIP installations can use "PHP Manager for IIS" to configure PHP installation with IIS.
| improve this answer | |
  • You can also get an installer package that will do all of the boring stuff for you here: windows.php.net/download. It got the FastCGI version of PHP 5.3.1 up and running perfectly on IIS, even though it was replacing an ISAPI version. – Jarett Millard Feb 5 '10 at 15:28
  • @Salman, You stated that non-thread-safe is for maximum stability, but isn't everyone using thread-safe versions? e.g. Apache doesn't work with non-thread-safe too right? – Pacerier Jun 25 '15 at 4:22
  • @Pacerier answer was written more 5 years ago and applies to IIS6. However, even today it is officially recommended to use non-thread-safe version with IIS+FastCGI (see php.net/manual/en/install.windows.iis7.php). – Salman A Jun 25 '15 at 7:08

I personally find for non busy websites (e.g. between 0-25 users on average) ISAPI works fine, I have found little benefit to using CGI over ISAPI.

However, If you have a busy website or do not mind putting a bit of work in to it, I recommend looking at FastCGI as you can now get it on Win2003 IIS6, It runs MUCH faster under heavy loads.


| improve this answer | |
  • So have you personally tried FastCGI? – Pacerier Jun 25 '15 at 4:49
  • @Pacerier - yep – William Hilsum Jun 25 '15 at 8:07
  • And is that a testplay site or a real big site with many concurrent visitors? – Pacerier Jul 2 '15 at 12:15

CGI performs very poorly on IIS as compared to the ISAPI model (since creating new processes, which is how CGI works, is very "expensive" in Windows NT-dervied operating systems). In modern versions of IIS many of the "probems" of ISAPI (memory leaks, needing to "recycle" applications, etc) are "fixed" and ISAPI-based applications generaly work very well and are easy to manage. Any reasons you find re: CGI-based applications being "better" than ISAPI-based applications were probably written in an IIS 4.0 or IIS 5.0-era mindset.

| improve this answer | |
  • What do you mean by "CGI-based applications being "better" than ISAPI-based applications" and how are they exactly "better"? – Pacerier Jun 25 '15 at 4:50
  • 1
    They aren't, in any meaningful sense. In the past some people thought they were. When the ISAPI ecosystem was "young" there were many ISAPI applications that suffered from stability issues (mainly because they were "leaky" when it came to resources). Some people saw CGI-based applications as more stable than ISAPI-based applications. CGI-based applications, starting as a fresh process for each request, didn't suffer from the resource leakage problems that a long-running application might. Now that the ISAPI ecosystem has matured any of these perceived advantages are, to my mind, gone. – Evan Anderson Jun 25 '15 at 8:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.