ianmcnaught's posterous

Testing Moodle 2.0 on Amazon Web Services

Wed, 22 Jun 2011 00:08:00 -0700

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

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!

Permalink | Leave a comment »

Moodle and Turnitin - a direct integration?

Mon, 30 May 2011 03:44:00 -0700

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.

First of all, I will list what I have found to be the good points. I have marked them as to whether they most benefit students, academics or admin.

The good

STUDENTS: On the whole, it is a better user experience for the student, as they never leave Moodle, all communication with turnitin is done in the background via their API.
ADMIN: Papers are stored locally in the Moodle file system as well as with Turnitin. Considering how hard turnitin makes it to download assignments from old modules, this is a great advantage when it comes to archiving, or just retrieving old assignments.
ADMIN: There are options added in the Course Reset page which can create duplicate turnitin assignments in preparation for your new term. This is a god send for end of term rollover where the basic integration is a nightmare (if you create a copy of the course, the course ID changes so the turnitin links break, if you just reset the course, the class lists and submissions from the previous term remain (and students remain active against your quota), if you delete the assignment you loose access to all submissions and only Turnitin support can restore it).
ADMIN: Because the assignment creation page is hosted on your Moodle install as a PHP file, you can easily change the default assignment settings to match your institutions needs. For example, if you want to allow late submissions by default, you can change the file and make this the default option for everyone (See here for instructions). Technically, you could even hide or disable certain controls if you wanted to actively prevent certain settings from being changed.
ACADEMICS: All the students will display in the assignment inbox without the need for Roster Sync. I have lost count of how many times in the past I’ve had staff worry about why they don’t have a full list of students in their inbox. The reality is this is never a problem, students will be added to the assignment when they submit, or to force it you can roster sync, but it does make staff uneasy, so it’s an advantage to not have to deal with this in the Direct integration.

As you can see, there are some considerable advantages to the integration, but most of them are of benefit to the Moodle administrator, not to student or academics, the more important stakeholders.

These are the issues I have found difficulties with, again categorised as a student, academic or admin issue.

The bad

ACADEMICS & ADMIN: Can’t download assignments as a batch. Actually you can, but only through turnitin.com if you are the assignment owner. This is relatively easy to setup once you know how, but a totally obtuse process that no one is going to work out on their own.
ACADEMICS & ADMIN: No way of downloading the grademarked paper from the assignment inbox, you can only download it from document viewer, so also again one at a time.
ACADEMICS: Only basic settings are available for creating an assignment. Key ones that are missing are the option to exclude small or cited matches. This can be set in the document view by applying a filter, but it would have to be done individually on every single paper submitted. It can’t be set as a global setting for the assignment. You can't even make these changes in turnitin.com because assignment settings for assignments created in Moodle are locked.
The most serious one: STUDENTS: Turnitin claiming that you can use both integrations at once, so we took their word for it and did. It turns out to not be quite so simple. Student accounts cannot be shared between the two integrations, so if they have submitted to both integrations, they will automatically have two accounts with turnitin, counting as two students on your quota of student accounts. We pay for 50 more accounts than we have students, but ran out of accounts with hundreds of students still trying to submit. This meant students couldn’t submit for quite a few days until turnitin acknowledged the problem and boosted our quota enough for us to get by. Lesson is, ignore what turnitin say and don’t use both at the same. It would be impossible to ensure that students were only submitting to one or the other.

What you no doubt notice here is that the benefits are heavily weighted towards Moodle administrators, and the disadvantages towards academics and students! Naturally if academics and students are having difficulties, it ends up on the desk of the administrator, so any benefits gained are soon wiped out!

Has anyone else used the direct integration? Would you agree with my assessment? Any issues I’ve missed out or misunderstood?

Permalink | Leave a comment »

Changing default assignment settings for Moodle Turnitin integration

Wed, 02 Feb 2011 00:10:00 -0800

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.

Permalink | Leave a comment »

Installing Apache, MySQL and PHP on Windows

Fri, 14 May 2010 07:36:00 -0700

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

Download the Apache .msi
Install for All users on Port 80 as a Service (this means it starts automatically when any user is logged in)
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).
Choose Typical installation
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

Install MySQL .msi (32 bit Essentials version, unless you have good reason to choose otherwise!)
Choose Typical Installation
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.

Permalink | Leave a comment »