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

Chris Miller, Director of Operations
08/09/2012, 11:38pm

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 setup 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 setup 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 /apachesolr_autocomplete?query=solr&limit=50&timestamp=1344579243483 was what we 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 setup, it’s hard not to recommend it as a first line choice for anonymous traffic. 

Contact Us

Jobst Consulting Inc

11150 West Olympic Blvd
Los Angeles, CA 90064
phone: 310.945.5948

Follow Us

Get a Quote

Contact us to find out how we can assist you as your IT needs grow and evolve. Together we can explore the possibilities.