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<br>MaxKeepAliveRequests 150<br>KeepAliveTimeout 5<br>ThreadsPerChild 250<br>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]<br>This is ApacheBench, Version 2.3 &lt;$Revision: 655654 $&gt;<br>Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/<br>Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking [server omitted] (be patient)<br>Completed 100 requests<br>Completed 200 requests<br>Completed 300 requests<br>Completed 400 requests<br>Completed 500 requests<br>Completed 600 requests<br>Completed 700 requests<br>Completed 800 requests<br>Completed 900 requests<br>Completed 1000 requests<br>Finished 1000 requests

 

Server Software:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Apache/2.2.22<br>Server Hostname:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [server omitted]<br>Server Port:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 80

Document Path:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /<br>Document Length:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 19416 bytes

Concurrency Level:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 100<br>Time taken for tests:&nbsp;&nbsp; 5.906 seconds<br>Complete requests:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1000<br>Failed requests:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0<br>Write errors:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0<br>Total transferred:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 19844040 bytes<br>HTML transferred:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 19563072 bytes<br>Requests per second:&nbsp;&nbsp;&nbsp; 169.32 [#/sec] (mean)<br>Time per request:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 590.605 [ms] (mean)<br>Time per request:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 5.906 [ms] (mean, across all concurrent requests)<br>Transfer rate:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3281.20 [Kbytes/sec] received

Connection Times (ms)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; min&nbsp; mean[+/-sd] median&nbsp;&nbsp; max<br>Connect:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 60&nbsp; 203 625.3&nbsp;&nbsp;&nbsp;&nbsp; 65&nbsp;&nbsp;&nbsp; 3089<br>Processing:&nbsp;&nbsp; 190&nbsp; 359 117.5&nbsp;&nbsp;&nbsp; 346&nbsp;&nbsp;&nbsp; 1196<br>Waiting:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 65&nbsp; 221&nbsp; 97.5&nbsp;&nbsp;&nbsp; 211&nbsp;&nbsp;&nbsp;&nbsp; 592<br>Total:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 255&nbsp; 562 643.4&nbsp;&nbsp;&nbsp; 414&nbsp;&nbsp;&nbsp; 4023

Percentage of the requests served within a certain time (ms)<br>50%&nbsp;&nbsp;&nbsp; 414<br>66%&nbsp;&nbsp;&nbsp; 462<br>75%&nbsp;&nbsp;&nbsp; 488<br>80%&nbsp;&nbsp;&nbsp; 521<br>90%&nbsp;&nbsp;&nbsp; 630<br>95%&nbsp;&nbsp;&nbsp; 962<br>98%&nbsp;&nbsp; 3448<br>99%&nbsp;&nbsp; 3516<br>100%&nbsp;&nbsp; 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. 

Tags: Planet Drupal , Windows 2008 Server , WAMP