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:
/apachesolr_autocomplete?query=solr&limit=50×tamp=1344579243483
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, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
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.
