ianmcnaught's posterous

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:

* 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

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.

* 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!

Note: This post is about integrating Turnitin with Moodle 1.9, if you have made the leap to 2.0 it may not be relevant to you. If you are assessing a turnitin integration for any other VLE, it's worth reading this post to see what things to watch out for.

If you read the turnitin blurb on their direct Moodle integration, it sounds fantastic. It offers a proper "moodle like" experience (rather than turnitin in a frame), and it gives the impression that you get the full feature set of turnitin, minus peer mark. Even better, you can run both integrations side by side, so you could keep the basic integration there for Peer mark, and use the direct one for everything else. We switched to this at the beginning of last semester (February. Funny time to switch, but we had our reasons), and have since found that everything is not quite as we expected. For the benefit of anyone else considering the direct integration, this is my review of the its good and bad parts.

Read the rest of this post »

The direct turnitin integration for Moodle is great, but there are a few tweaks necessary to set it up correctly. The default settings for a new assignment created through Moodle do not match the defaults in turnitin.com, and unlike turnitin.com there is not an option to save a selection of default settings (as far as I can tell through reading turnitin's limited documentation). However, even on turnitin.com, the defaults you save are course-wide not institution-wide, so not so helpful if your institutions policies are different to the turnitin defaults.

This is where using the integration gives you advantage over using turnitin.com, because you have access to the code! Open MOODLEDIR\mod\turnitintool\mod_form.php in a text editor, and you should find several lines of code like this:

$mform->setDefault('allowlate', 0);

You should be able to work out what most of them relate to by the first word after the open brackets - this word is the "name" attribute of the form element, the value following is the value to be used as default. So using the example above, if you wanted to change it so by default it allowed late submissions (I don't understand why this wouldn't be the default!), change the value at the end of this line to a 1.

I hope this helps some people, as I couldn't find any existing instructions on how to do this. I'd rather not hack the code of the plugin, as it is bound to come back and bite me after a future upgrade, but as far as I can tell - it's the only way to do it. If I've missed something really obvious here, please let me know in the comments.