#IIS Hacks

Server & System Administration Archive · 2007–2013

An independent, non-commercial archive. Not affiliated with, endorsed by or connected to any vendor named in these notes.

Macro cross-section of a bundled fibre trunk catching cool directional light

PHP

PHP was never a Microsoft product, which is why it generated so many notes on a Windows server blog. A large share of the applications administrators had to host between 2007 and 2013 — blogs, forums, galleries, shopping carts — were written in PHP by people working on Unix, while the machine available to run them was Windows Server with IIS in front of it. These notes record the closing of that gap.

Why PHP on Windows was hard

PHP was built and tested overwhelmingly on Unix. Windows was supported rather than primary: the binaries lagged, the bundled extension set was smaller, many third-party extensions had no Windows build at all, and application code routinely assumed a Unix filesystem, a Unix mail transport and a Unix path separator without noticing that it had. The early notes here are almost all of that character — a function behaving differently under IIS 6, an extension DLL that will not load, a content management system that breaks against one particular interpreter release.

The hosting model compounded it. The fast way to run PHP under IIS was as an ISAPI extension: a DLL loaded straight into the web server's worker process and resident between requests. Plain CGI started a fresh interpreter for every request and threw it away, and on a busy site that cost dominated everything else. But an in-process interpreter runs on the server's threads and in the server's address space, which turns thread safety from an implementation detail into an operational property, and a fault in any loaded extension into a fault in the web server itself.

That is why PHP for Windows was published in two forms, thread-safe and non-thread-safe, and why choosing the wrong one produced intermittent, load-dependent failures that were close to undiagnosable. The requirement propagated to everything the interpreter loaded, which is where the opcode caches of the period — eAccelerator, xCache and APC — became decisive: what they supported determined which hosting model a busy Windows site could use. Installing PHP ISAPI on Windows 2008 IIS 7 x64 is that era's procedure.

From ISAPI to FastCGI

The move out of that arrangement was right. FastCGI runs the interpreter as separate, long-lived php-cgi.exe processes that IIS starts, keeps alive across requests and communicates with over a defined protocol. It keeps what made ISAPI fast — no process start per request — while removing what made it fragile: a crash or a leak is contained in one interpreter process rather than taking down a worker serving every request, and single-threaded processes retire the thread-safety requirement.

Two things then closed the argument. PHP 5.3 stopped shipping an ISAPI DLL for Windows, so staying on that route meant compiling the interpreter; and opcode caching became available in the non-thread-safe model, removing the last performance reason to keep the interpreter inside the server. Installing PHP 5.3 FastCGI on Windows 2008 IIS 7 is where the archive lands, and its outline — FastCGI, the non-thread-safe build, PHP Manager for per-site versions — is still the supported shape.

Two neighbouring notes belong to the same story. MySQL connection response slow on Windows 2008 and 2012 is the last post the site published on the subject: a PHP application made slow by name resolution rather than the database it was blamed on. And migrating websites from IIS 6 to IIS 7 ends by noting that PHP is configured separately after the migration — the interpreter was never part of the IIS configuration being moved.

What has changed since

Almost everything version-specific here is obsolete, and the platform problem behind it has gone away. PHP for Windows is built and published officially, at windows.php.net, and the PHP manual's Windows installation chapter supersedes every install procedure recorded in these notes. The accelerators named above are superseded too: OPcache has been bundled with the interpreter since PHP 5.5.

What changed the picture more is where PHP is run at all. PHP-FPM, the process manager that became the standard way to host it, is a Unix facility with no Windows equivalent, and containerised Linux runtimes put a Linux host within reach of anyone running a Windows estate. Hosting PHP on Windows became a deliberate choice rather than the default consequence of owning Windows servers — which is the honest explanation for why this section stops in 2013. IIS itself is still current and documented at Microsoft's IIS documentation.

Notes filed under PHP

Linked titles are restored pages. Plain titles record what was published at that URL; the full corpus is indexed in the complete post archive, and the wider web-server material sits under Internet Information Server.