Testing Moodle 2.0 on Amazon Web Services

As part of our investigation into more flexible hosting for Moodle next adademic year, we have been doing some quite extensive testing on Amazon Web Services (AWS). The first step was to ascertain what EC2 instance type we would need for acceptable Moodle performance. From this we would be able to project the total costings for a years worth of hosting. To conduct this test, we setup a basic webserver (Ubuntu server and Lighttpd) and a small RDS instance for the database. We installed Moodle on the webserver, setup a few courses, users and activities, created an AMI (Image) of it so we could launch identical instances later, then started some load testing.

The load testing

We used Apache Jmeter to conduct the load testing. We setup a simple script simulating user activity (logging in, loading a few courses and clicking around on some activities), then set it to run the test with 10 simultaneous users repeating it 10 times. We tried this on four different instance types: Micro, Small, Medium (High CPU) and Large. The spec of these instances is below:

Name CPU Memory I/O Price/hour
Micro Up to 2 EC2 Compute Units* 613 MB Low $0.025 or Free
Small 1 EC2 Compute Units 1.7 GB Moderate $0.095
Medium, High CPU 5 EC2 Compute Units 1.7 GB Moderate $0.19
Large 4 EC2 Compute Units 7.5 GB High $0.38

* Instances of this family provide a small amount of consistent CPU resources and allow you to burst CPU capacity when additional cycles are available.

The question is, which is the cheapest instance that could give us acceptable load times, and which would perform best between large (high memory, less CPU) or medium, high CPU (less memory, more CPU)? Each system was identical, except for the hardware spec. The tests performed on them was also identical. The aim of this was not to get an idea of actual Moodle performance on AWS, the webservers were not in anyway optimised - the aim was twofold 1) to get an idea as to which instance type would give us best performance for the money, and 2) to compare performance with an identically setup server hosted in house.

Results

The results are displayed in the graphs below

Chart21

Chart32

As you can see from the graphs above, the Micro instance performed very badly (and erratically - not suprising seeing as it has low I/O performance, and no guaranteed level of CPU), the Small and Large instances performed more consistantly and gave an improvement in line with their specification, but the best performer by a small margin was the Medium, High CPU instance. This is especially useful to know considering the cost saving between that and a large instance (see below). I haven't included the Micro instance in the price comparison due to the fairly unusable performance, but it could be useful as a staging server.

Instance Type Annual RDS Cost* Annual Instance Cost* Total
Small $578.13 $744.68 $1,322.82
Medium, High CPU $578.13 $1,156.27 $1,900.95
Large $578.13 $2,312.53

$3,057.21

* These prices are taking into account the discount you get when you pay for a reserved instance.

Of course the prices above are for running a constant server throughout the year, which would kind of defeat the object of hosting in the cloud. In reality, some periods of time you might switch to a larger instance for a couple of weeks, then maybe during the summer just to keep it ticking over, you'd switch to a small, or even micro instance. The prices displayed give an indication of price, but should not be relied on too heavily.

Further optimisation

These tests have been conducted on a very basic, non-optimised webserver. With a little work, better performance could be coaxed out of any of them. As well as the standard tweaks you might do (Opcode caching, file compression and in memory cache), AWS also offers some great tools for improving your sites reliability and performance. Briefly, these are a few things you could do:

  • Use Amazon Cloud Front as a Content Delivery Network for serving static files
  • Use Elastic Load Balancing to share the load between multiple web servers (although you'd need some form of network attached storage, or S3 for your moodle data so all the web servers could access it).
  • Setup some auto scaling rules to automatically scale your resources up or down, depending on demand.
  • Take advantage of RDS' ability to easily setup a read replica for your database
  • Configure your RDS database to have a multi A-Z deployment (keeps a hot standby in another availability zone for instant failover if the main one goes down).

Hopefully this data is useful to people. If you have any experience setting up a production Moodle deployment on AWS, I'd love to hear from you!