Load Testing Drupal – LoadStorm
Drupal is one of the most popular open source content management platforms and is being adopted at ever larger organizations because of its powerful features.
Our team is conducting load testing against copies of Drupal on various sizes of EC2 instances. We intend to establish performance benchmarks for Drupal version 6.x.
If you are a Drupal developer and want to join us in the fun, please make a comment to this post or contact Scott Price at [email protected].
Other have previously established benchmarks for Drupal 5.x versus 4.7. Do you know of other Drupal benchmarking studies? Please share them with us.
There are many questions that can be asked, and we set out to answer as many as possible. Some key questions that we wish to answer:
- How can you get Drupal to perform at an optimal level?
- What are the affects of application caching?
- How many concurrent users can different servers support without performance degradation?
- Which database settings produce the greatest performance improvements?
- How can you tell if you are tuning Drupal to get the best performance?
- What Apache configuration settings impact Drupal performance?
To do a performance case study justice, this will not be a simple or quick process. Our goal is to publish a series of articles on our load tests, performance results, tuning, and conclusions.
We thought of this concept before LoadStorm was even a finished product, and Christian Romano’s introduction laid the groundwork for what we wanted to do. Now we have begun the testing and intend to publish this complete series in the next few weeks. We welcome your input and feedback regarding any aspect of this study.
Primarly, our methodology will be to “keep it as simple as possible”. Crawl – before walking – before running. We will get more advanced in our performance engineering techniques as we progress.
The fundamental process will be to install the application in a neutral environment so we can test it and establish baseline metrics without any modification to the “off the shelf” configurations. Specifically, we want to establish a basic Drupal install, run the simplest load tests, and make obvious configuration changes to measure performance.
We will use a LAMP stack on small, large, and extra large Amazon EC2 server instances. Our Drupal application has 1,000 users and 10,000 pages. We didn’t change any of the default settings of Drupal, Apache, or MySQL. We left everything as it comes out of the box. Remember crawl first…
The Amazon network pipe is essentially unlimited, so we knew that bandwidth would not be an issue. Our objective was to isolate any change in performance to the Drupal/Apache/MySQL configuration.
In 2008 when the Drupal Project announced the official release of Drupal 6, they made this statement:
“Dramatic Performance Improvements. All these new features come with an added bonus – higher performance. In addition to high-performance caching for anonymous users, Drupal 6 offers a host of under-the-hood optimizations that speed up sites with large numbers of logged-in users.”
Let’s find out how dramatic the higher performance really is. This should be fun and interesting.
We hope you get value from these test results. Each round of testing will have its own post, and I will summarize the results here.
Anonymous Users
Please review the details of this first series of load testing in the post Load Testing Drupal – Anonymous Users.
| EC2 Instance | Caching | Users | Requests/sec | Avg Response | Error Rate | Result |
|---|---|---|---|---|---|---|
| Small | Off | 67 | 1.63 | 5 sec | 0% | Failure |
| Small | On | 100 | 2.7 | 0.34 sec | 0% | Success |
| Small | On | 500 | 14 | 0.68 sec | 0% | Success |
| Small | On | 926 | 28 | 0.53 sec | 0% | Success |
| Small | On | 1000 | 10.6 | 22.8 sec | 81.5% | Failure |
Key performance data point: Normal page caching increases anonymous user requests/sec processing by 1,718%.