Note: This is Part 3 of an ongoing series on Drupal performance and load testing. If you haven’t already, read the introduction.
We added to our existing research by configuring a dual-server reverse-proxy system using Drupal and a commercially available product called aiCache.
Compared to a single-server installation, aiCache:
We invited engineers from aiCache and a team of Drupal experts from Achieve Internet, who configured a slightly customized Drupal that could inter-operate with aiCache. AiCache, running on a separate Amazon instance, cached all static content and content intended for anonymous users. Dynamic content for users with individual log-in accounts passed through aiCache and were generated by Drupal itself.
Our load test included validators to verify correct operation of the site, for example, that users actually saw their user IDs after logging in.
Our modified Drupal instance was built on Pressflow, had all of the basic optimizations turned on (APC, caching, etc) and a custom module that allowed Drupal to inter-operate with aiCache. This Drupal instance required only a few hours to implement and didn’t impair the user experience.
The test profile was identical to our previous tests against stock Drupal and the Pantheon Drupal Platform, except that the test was configured to ramp up to 6,000 users over two hours. To get an apples-to-apples benchmark of aiCache’s performance, we tested both Drupal via aiCache and the Drupal backend without aiCache.
In our previous case studies, we set two performance goals for all test platforms: error rates must be less than 0.1%, and average durations for all pages must be less than four seconds.
According to this standard, raw Drupal, on the hardware provided, served up to 800 simultaneous users, but Drupal sitting behind aiCache served up to 3,200 simultaneous users.
But, there’s more to this story than simultaneous user level, because aiCache has the ability to continue serving content even when Drupal does not. When raw Drupal failed, the entire site became unusable. But when Drupal with aiCache failed, aiCache faithfully continued serving content. Anonymous users browsing the site with aiCache enabled never encountered a single error.
Raw Drupal printed its first error 9 minutes into the test, but Drupal with aiCache didn’t print an error until 1 hour into the test.
With cacheable content we see a relatively clean graph with a few spikes (by the way, the yellow line is the most interesting from a load-testing perspective. The red and pink lines represent upper and lower outliers.):
For a task that was mostly dynamic, that is, that required a lot of work from Drupal because it involved updating data tables or incorporating user-specific elements, performance was significantly impaired:
Our test scenario was quite harsh considering the architecture of reverse-proxy caching systems, because three of the four test cases depended heavily on application logic that only Drupal can perform. We also allowed the engineers at aiCache and Achieve Internet only a few hours to optimize the installation. Yet, we were still able to quadruple the capacity of our system while only doubling the hardware.
We were also able to break down different functions of the web site using Web Performance Load Tester — demonstrating clearly which site functions were being optimized by aiCache and which functions were not. I can state confidently that the system we deployed was limited by the number of users contributing dynamic content, but could scale to support many thousands of casual anonymous visitors.
— Lane, engineer at Web Performance