Drupal on Windows Server: How and Why

April 1st, 2011 Permalink

Drupal is, as I'm sure you are aware, a PHP-based combination of a web development framework and content management system. The Drupal community is energetic, and has constructed a vast array of plug-in extensions, themes, and modules over the years. This can allow for very rapid web development under some circumstances, such as when (a) scaling to high traffic or large datasets is not required, and (b) the project requirements are fairly loose. With the sheer volume of third party projects and modules out there, it is fairly easy to produce a Drupal site that is close to any given set of high level requirements - but much harder to enable that site to work at scale, or meet very detailed and specific requirements.

Drupal is very much a part of the LAMP ecosystem, and so there are really only two scenarios under which you would find yourself setting up a Drupal website on one of the many varieties of Windows Server:

  • You are working for a Microsoft shop whose managers have decided that they will branch out into PHP in order to build a Drupal site, but who nonetheless carry on using Windows Server to host that site - and cannot be persuaded otherwise.
  • You are somewhat masochistic and enjoy making your life unnecessarily difficult.

So let us say that, for whatever reason, you find yourself in the unenviable position of deploying a Drupal website on some version of Windows Server. What are your options? Fortunately, PHP, MySQL, and Apache are both freely available and reliable on Windows Server, either as stand alone installations or part of a package like XAMPP, WampServer, and so forth. The worst thing that is likely to happen is that you'll get strange looks when you tell people that you are deploying on Windows.

The real challenge lies not in running the LAMP basics on Windows Server, but rather in the fact that any significantly sized Drupal site will perform poorly in the absence of a byte-code cache and in-memory cache. Here, unfortunately, the low-cost options on Windows are far more limited - but still very necessary. Consider that in response to a single HTTP request for a logged in user, Drupal may make hundreds of SQL queries, load and parse a hundred PHP files, and issue thousands of function calls. This cries out for caching, and on a Linux system you would simply do the following - which might take you all of five minutes and cost nothing beyond the time taken:

  • Install APC as a byte-code cache (meaning a given PHP file only has to be interpreted once rather than with every page load).
  • Install Memcached as your in-memory cache (meaning that cached objects can typically be retrieved far more rapidly than from their default location in the database).
  • Turn on the Query Cache in MySQL as an additional layer of in-memory caching.
  • Assuming you are using Drupal 6, add the Cache Router module and configure it to use Memcached.

For Windows, the situation is far less convenient. As of early 2011, there is no reliable Memcached distribution for Windows Server that will "just work" absent a developer who knows a great deal about (a) compilation on Windows and (b) the issues that typically crop up in porting a Linux codebase to Windows. Developers with this focus and level of knowledge are next to non-existent in web development shops - in my experience, at least.

There are a few Memcached binary distributions for Windows out there, none of which work well across a range of different Windows Server versions. The problems I have experienced with Memcached on Windows have ranged from the obvious and immediate to very subtle issues that may not show up for weeks after installation. For example, one of the binary builds I tried falls into a death spiral of slow responses on Windows Server 2008 after a few days of uptime, and crashes intermittently on Windows 7.

For byte-code caches that come packaged as PHP extensions (compiled into DLL files on Windows) you might look at eAccelerator or XCache. Unfortunately, both suffer from much the same type of issue as Memcached on Windows. The available binary distributions I have tried are unreliable on Windows 7 and Windows Server 2008, causing intermittent crashes and other issues. In order to produce and maintain a good, reliable build from source that will play well with PHP's binary Windows distribution you will again need a developer who, as a minimum, has a good understanding of compilation on Windows.

So this really only leaves the professional packaged distributions of PHP in the running. If you want to run PHP on Windows Server with a byte-code cache that just works, and without the exercise costing an arm and a leg, then your options are limited to:

1) Zend Server Community Edition: A packaged distribution of Apache, PHP, and its own byte-code cache called Zend Optimizer. MySQL is an optional component, but if you want the latest version of MySQL - and to avoid potential problems I've seen with installations failing on the MySQL component used by the Zend Server CE installer - then you'll have to install it separately.

2) PHP on Windows: A conceptually similar package for the IIS web server. It includes PHP and a byte-code cache called Windows Cache Extension.

For my part, I prefer to work with Apache over IIS if I have to use Windows Server, and that choice is largely based on a preference for configuration files over configuration GUIs rather than any more technical complaint. Either Zend Server or PHP on Windows will get the job done for any site that isn't required to scale to high levels of usage, and with a minimum of effort and specialist knowledge. The average web development shop will not have the in-house skills to go much beyond this, and will just have to forge ahead without using Memcached or any of the standalone byte-code caches on Windows Server.

At least it's still possible to turn on the Query Cache in a Window Server installation of MySQL. Small consolation, but the situation it is what it is. The lesson to take away from this examination of the landscape is that it is well worth objecting to any decision to host a Drupal site on Windows - and doubly so if that site is expected to handle significant traffic.