lamp performance on the elastic compute cloud: benchmarking drupal on amazon ec2
in this article we get a sense of lamp performance on ec2 by running a series of benchmarks on the drupal cms system. these benchmarks establish read throughput numbers for logged-in and logged-out users, for each of amazon's hardware classes.
we also look at op-code caching, and gauge it's performance benefit in cpu-bound lamp deployments.
the elastic compute cloudamazon uses xen based virtualization technology to implement ec2. the cloud makes provisioning a machine as easy as executing a simple script command. when you are through with the machine, you simply terminate it and pay only for the hours that you've used.
ec2 provides three types of virtual hardware that you can instantiate. these are summarized in the table below.
|machine type||hourly cost||memory||cpu units||platform|
|small Instance||$0.10||1.7 GB||1||32-bit platform|
|large Instance||$0.40||7.5 GB||4||64-bit platform|
|extra large Instance||$0.80||15 GB||8||64-bit platform|
|note: one compute unit provides the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor.|
to keep things relatively simple, the target deployment for our load test is basic; the full lamp stack runs on a single server. this is step zero in the five deployment steps that i outlined in an open-source infrastructure for high-traffic drupal sites.
our benchmarkour benchmark consists of a base drupal install, with 5,000 users and 50,000 nodes of content-type "page". nodes are an even distribution of 3 sizes, 1K, 3K and 22K. the total database size is 500Mb.
during the test, 10 threads read nodes continually over a 5 minute period. 5 threads operate logged-in. the other 5 threads operate anonymously (logged-out). each thread reads nodes randomly from the pool of 50,000 available.
this test is a "maximum" throughput test. it creates enough load to utilize all of the critical server resource (cpu in this case). the throughput and response times are measured at that load. tests to measure performance under varying load conditions would also be very interesting, but are outside the scope of this article.
the benchmark runs in apache jmeter. jmeter runs on a dedicated small-instance on ec2.
benchmarking is done with op-code caching on and off. since our tests are cpu bound, op-code caching makes a significant difference to php's cpu consumption.
our testing environmentthe tests use a debian etch xen instance, running on ec2. this instance is installed with:
- MySQL: 5.0.32
- PHP: 5.2.0-8
- Apache: 2.2.3
- APC: 3.0.16
- Debian Etch
- Linux kernel: 2.6.16-xenU
the tests use a default drupal installation. drupal's caching mode is set to "normal". no performance tuning was done on apache, mysql or php.
the resultsall the tests ran without error. each of the tests resulted in the server running at close to 100% cpu capacity. the tests typically reached steady state within 30s. throughputs gained via jmeter were sanity checked for accuracy against the http and mysql logs. the raw results of the tests are shown in the table below.
|instance||apc?||logged-in throughput||logged-in response||logged-out throughput||logged-out response|
note: response times are in seconds, throughputs are in pages per minute
the results - throughputthe throughput of the system was significantly higher for the larger instance types. throughput for the logged-in threads was consistently 3x lower than the logged-out threads. this is almost certainly due to the drupal cache (set to "normal").
throughput was also increased by about 4x with the use of the apc op-code cache.
the results - response timesthe average response times were good in all the tests. the slowest tests yielded average times of 1.5s. again, response times where significantly better on the better hardware and reduced further by the use of apc.
conclusionsdrupal systems perform very well on amazon ec2, even with a simple single machine deployment. the larger hardware types perform significantly better, producing up to 12,500 pages per minute. this could be increased significantly by clustering as outlined here.
the apc op-code cache increases performance by a factor of roughly 4x.
these results are directly applicable to other cpu bound lamp application stacks. more consideration should be given to applications bound on other external resources, such as database queries. for example, in a database bound system, drupal's built-in cache would improve performance more significantly, creating a bigger divergence in logged-out vs logged-in throughput and response times.
although performance is good on ec2, i'm not recommending that you rush out and deploy your lamp application there. there are significant challenges in doing so and ec2 is still in beta at the time of writing (Jan 08). it's not for the faint-of-heart. i'll follow up in a later blog with more details on recommended configurations.
if you found this article useful, and you are interested in other articles on linux, drupal, scaling, performance and LAMP applications, consider subscribing to my technical blog.
- amazon web services home
- getting started with ec2
- alternative php cache (apc)
- load test your drupal application scalability with apache jmeter