Tuning Drupal on Windows 2008 Server, Apache 2.2, PHP 5.3 & Boost Module

Here at STAUFFER we do a lot of work with universities, and often times our options are limited in choices of server hardware and platform configuration options. A recent university client required that we build a production environment on Windows 2008 Server setup on a virtual machine provisioned from the university’s central IT department.

We did a standard deployment of Drupal from our staging environment to their server, sans caching, which would be enabled following the completion of user acceptance testing and content entry.  We immediately ran into a whole host of issues when we first tried to visit the newly set up site, including:

  • Apache was throwing errors and crashing in under an hour
  • Page Responsiveness & Load Times up to 11 seconds
  • Solr Responsiveness over 6 seconds!

Ouch. The server initially was set up as a 6GB RAM WAMP server as follows:

  • Windows 2008 Server 64-bit
  • Apache 2.4
  • MySQL 5.5
  • PHP 5.4
  • Solr on Tomcat 7

We needed to solve the uptime issues before we could dig into the other outstanding problems, so Apache and PHP became the first targets. Some googling and discovery led us to believe that both Apache 2.4 with PHP 5.4 were unreliable on Windows 2008, so we decided to downgrade Apache to 2.2 and PHP to 5.3.13. Fortunately, this was a simple solution and solved the crashing problem immediately.

Next we moved over to the page speed issues. Even with being on a quality university pipe, this server was just too slow. We used “ab” (Apache Bench) to get some baselines on where we stood. At 25 requests at 5 concurrency we were at nearly 11 seconds per request to the homepage. Time to configure Apache and PHP.  

Standard Apache configuration additions to the httpd.conf included:

  • KeepAlive On
  • MaxKeepAliveRequests 150
  • KeepAliveTimeout 5
  • ThreadsPerChild 250
  • MaxRequestsPerChild 0

Additionally, we disabled unneeded Apache modules, setup Alternative PHP Cache, and bumped up the php memory limit in php.ini to 256M. Running the same Apache Bench produced a sub 5 second response without enabling any Drupal caching mechanisms. Much better, and a lot closer to healthy.

We were still experiencing 6 second Solr responses on the Apache Solr autocomplete, which was terrible for a pretty much a standard installation from the contrib module. Running AB against the autocomplete callback url at:


was used to target the benchmark, and with Apache and PHP performing adequately we turned our attention to Tomcat. Typically we use Jetty for our Solr setups, and not knowing really where to begin with Tomcat we simply decided to run Jetty instead.

Surprisingly this brought Solr performance back into the expected response speeds, with queries returning in the 1.5-2 second range. We allocated 2GB of memory to the Jetty service and Solr was then performing in the 1.2-1.5 range.

Satisfied with our results, we then enabled Drupal CSS & JS aggregation as well as setup Boost module. Boost produced the most dramatic results, dropping our mean response time for 1000 requests at 100 concurrency. Here are the final results:

ab -c 100 -n 1000 [server omitted]

This is ApacheBench, Version 2.3 <$Revision: 655654 $>

Copyright 1996 Adam Twiss, Zeus Technology Ltd,

Licensed to The Apache Software Foundation,

Benchmarking [server omitted] (be patient)

Completed 100 requests

Completed 200 requests

Completed 300 requests

Completed 400 requests

Completed 500 requests

Completed 600 requests

Completed 700 requests

Completed 800 requests

Completed 900 requests

Completed 1000 requests

Finished 1000 requests


Server Software:        Apache/2.2.22

Server Hostname:        [server omitted]

Server Port:            80

Document Path:          /

Document Length:        19416 bytes

Concurrency Level:      100

Time taken for tests:   5.906 seconds

Complete requests:      1000

Failed requests:        0

Write errors:           0

Total transferred:      19844040 bytes

HTML transferred:       19563072 bytes

Requests per second:    169.32 [#/sec] (mean)

Time per request:       590.605 [ms] (mean)

Time per request:       5.906 [ms] (mean, across all concurrent requests)

Transfer rate:          3281.20 [Kbytes/sec] received

Connection Times (ms)

            min  mean[+/-sd] median   max

Connect:       60  203 625.3     65    3089

Processing:   190  359 117.5    346    1196

Waiting:       65  221  97.5    211     592

Total:        255  562 643.4    414    4023

Percentage of the requests served within a certain time (ms)

50%    414

66%    462

75%    488

80%    521

90%    630

95%    962

98%   3448

99%   3516

100%   4023 (longest request)

From 11 seconds for 5 concurrent users down to 590 milliseconds for 100 concurrent. Not bad, and considering how easy Boost is to set up, it’s hard not to recommend it as a first line choice for anonymous traffic.

Did You Know...

Stauffer can help you navigate security considerations on your digital systems.

Contact Stauffer

We look forward to hearing from you!

    How Would You Prefer We Get Back To You?

    EmailPhone Call

    May We Add You to our Mailing List?

    Yes, please send me your emails (once per month)

    protected by reCAPTCHA PrivacyTerms


    Contact Us

    [email protected]

    Los Angeles

    11150 W Olympic Blvd, Suite 1170
    Los Angeles, CA 90064

    Get Directions | 424.239.6025


    10363 104 St NW
    Edmonton, AB T5J 1B9

    Get Directions