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.

This post is primarily for my benefit, to document a process I have gone through many times before, but hopefully it might be useful to some other people who want to use AMP (Apache, MySQL, PHP), but are forced for whatever reason to use it with Windows rather than the Linux. If you spot any mistakes or omissions, please let me know in the comments.

Before we start this process, if you are just after a simple install of the “AMP Stack” on Windows, you might want to check out one of the excellent bundles such as WAMP Server and XAMPP. These make it very easy to do everything I describe in this post through a simple install Wizard. So why install them separately? Mainly because it keeps you in control and helps you to understand how the 3 components interact. The packages are great to get you going, but if you haven’t installed and configured these applications yourself, it is difficult to diagnose and fix problems when they inevitably occur.

Apache

1. Download the Apache .msi
2. Install for All users on Port 80 as a Service (this means it starts automatically when any user is logged in)
3. Give a suitable Admin email address, Network Domain and Server Name can remain as default unless you have reason to change. (If this is just a development machine, you can leave this as default).
4. Choose Typical installation
5. If installation appears to have been successful, type either localhost or 127.0.0.1 into your web browser and it should say “It worked!”

Document Root

The Document Root is the directory where all the files you want to be accessible to your web visitors go. Nothing outside of this directory is accessible to users through a web browser. By default on Windows this directory is in C:\Program Files\Apache Software Foundation\Apache2.2\htdocs but you may want to move it somewhere else either for simplicity or to make backups easier. If you wish to do this, open httpd.conf, search for the DocumentRoot line and change to wherever you want it to be. Important Note: Any changes to httpd.conf require a restart of Apache before they take affect. To do this, double click on the Apache icon in the task bar and click Restart. MySQL

1. Install MySQL .msi (32 bit Essentials version, unless you have good reason to choose otherwise!)
2. Choose Typical Installation
3. Choose “Configure MySQL Server now” on the last part of wizard Most of the settings can remain as default unless you have reason to change, however make sure that sufficient concurrent users are allowed, and that it is set to run as a service. If this is a public web server, ensure a secure root password is created when asked. If this is a private development machine, you can untick the modify security settings box and the root account will have no password.

Optional Step: Install SQLyog community edition. This is a great database management tool, it allows you to create databases, browse them and query them. It is invaluable for administrating databases, but it is not required on the Server, it can be installed on your local machine and connect to the database installed on the server. PHP

Download the VC6 Threadsafe version from the PHP Windows download page. Although there are MSI versions of PHP that in theory install everything for you, I have always found it easier and more reliable to use the manual installation method described here.

• unzip to C:/PHP (could be anywhere, but update path references below if you choose a different location)
• Change either php.ini-development or php.ini-production (depending on the purpose) to just php.ini.
• make the following alterations to c:/php/php.ini. Search for these lines, alter as shown or if not present, add them. (Some or all of them may be present, but “commented out”, with a ; character at the beginning of the line.

Configuring PHP

PHP comes with a number of extensions. You won’t need them all, and shouldn’t activate them unless you need them, but you will certainly want the MySQL drivers. Below are my suggested minimum changes to your php.ini file:

short_open_tag = On
max_execution_time = 60
upload_max_filesize = 10M
auto_detect_line_endings = On ;(makes it compatible with text files created on mac/unix)
extension_dir = "C:\php\ext"
extension=php_mysql.dll
extension=php_mysqli.dll

Most of these configurations will already exist in your php.ini, so do a search for them before adding them. Some may be “commented out” which means the line is not active, you can tell if this is the case if the line starts with a semi colon. Removing this semi colon will activate this line. Normally after changing php.ini you will need to restart Apache before you benefit from the changes, but at this point we haven’t configured Apache to use PHP, so it makes no difference. We’ll get onto that now. Configuring Apache

The final stage of this process is to configure Apache to use PHP. There are two changes you need to make, both in the httpd.conf file which should be in the following directory: C:\Program Files\Apache Software Foundation\Apache2.2\conf\

First add these lines to the file:

LoadModule php5_module "C:/php/php5apache2_2.dll"
AddType application/x-httpd-php .php
PHPIniDir "C:/php"

The first of those lines loads the php module, the next one registers php files as a valid type for Apache to load, the final line sets the directory where the php.ini file can be found. For the next step, search for the directive DirectoryIndex and add index.php to the list. It should end up looking something like this

DirectoryIndex index.html index.htm index.php

It may have more file types to it, you can leave them or keep them. These are the file names and extensions that you want Apache to load up by default when someone navigates to a directory on your site not an explicit page. They are prioritised from left to right, so if more than one index page is found it will load the left most listed one. With this in mind, you may wish to put index.php first, but there is probably no need to.