System Requirements
Rogō runs on a standard LAMP stack:
- Apache 2.2
- mod_SSL
- MySQL 5.1 (or above) - NOTE: Mysql 5.7 is not currently compatible.
- PHP 5.3.2
- GD Library
- cURL
- php5_ctype (may not be installed by default on some Linux distros)
- php-mbstring extension required
- php-xml extension required
- php-xmlrpc extension required
- php-mysqli extension required usually labeled as php-mysql on package managers
To use LDAP for authentication or lookup:
- php-ldap extension required
N.B. Rogō is being used on Linux and Solaris servers for all known installations in the community. However, as Rogō runs on a LAMP stack there should be no issues with it running on a Windows server.
The instructions below are for an in development branch of Rogo
From Rogo 6.1 the install and update scripts will check that the listed extensions are installed before letting you proceed.
<?xml version="1.0"?> <rogo> <version>6.1.0</version> <php> <min_version>5.3.9</min_version> <extensions> <extension>mysqli</extension> <extension>mcrypt</extension> <extension>curl</extension> <extension>gd</extension> <extension>ctype</extension> <extension>mbstring</extension> <extension>xml</extension> <extension>xmlrpc</extension> <extension>fileinfo</extension> </extensions> </php> <database> <mysql> <min_version>50100</min_version> </mysql> </database> <webserver> <apache> <min_version>2.2</min_version> </apache> </webserver> </rogo>
Hardware Recommendations
Running on-line summative assessments requires a stable hardware platform with enough resources to handle the current student numbers and predicted growth in numbers. Rogo is a web application based around the LAMP stack and many of the standard optimisation techniques are applicable. However, on-line summative assessments have a different load profile to normal web traffic caused by the start of the exam. This high load over a short time period and the importance of the consequence of hardware failure must be taken into account.
Below are some sample/example based systems.
Small-Scale/Trial
CPU | 1x Quadcore |
RAM | 4Gb |
Hard Disk | 8Gb (RAID recomended for reliability NOT 0,2,3,4, for this size of space RAID 1 is adequate) |
Large-Scale/Summative
CPU | 2x Quadcore |
RAM | 8Gb |
Hard Disk | 20Gb (RAID recomended for reliability NOT 0,2,3,4, for this size of space RAID 1 is adequate) |
Example University of Nottingham platform
CPU | 4x Quadcore AMD Opteron(tm) Processor 8356 2300MHz |
RAM | 16Gb |
Hard Disk | 4 x 250Gb (RAID 5) |
PSU | 4x redundant |
Network | 2x Gbit |
Considerations
- Redundancy of Hardware This includes multiple PSUs (This allows either one source of power to fail or a failure of a PSU) and multiple networks (This allows either network hardware failure/routing issues or can increase the server bandwidth) along with Redundant storage solutions (allowing a disk failure to not interrupt the service and often provide higher performance than a single disk).
- Availability - the design of supporting architecture should mirror the risk associated with failure. For high-stakes summative exams this normally requires a higher level of risk mitigation than simple formative self-assessments, for example. There are two main models of availability possible: 1. Automatic high-availablity - virtual machines or load balancers are used to seamlessly flow requests between multiple servers in case of failure. In main cases the aim is that end users will not even notice that traffic has been routed to a different server. This will also require HA or cluster mysql setup. 1. Manual fall-over - two machines of identical specification can be used in a 'live' and 'backup' configuration. Usually the database would be configured as 'master' on the live server and 'slave' on the backup to keep records synchronised in real-time. Files (e.g. images) can be copied between servers using cron jobs set to run each day. In the event of a failure in the live the master/slave database connection would be broken by the system administrator and students told to re-start the exam on the backup server. Worst case scenario would be that one screen of results could be lost. This is the simplest method and has been implimented at Nottingham for many years without actually needing to being used.
- Load - web-servers can handle thousands of users spread out over a period of time, but with summative exams high loads are imposed at the start of the exam and also we have seen at the end when students are quickly navigating between screens checking answers.
- Bandwidth - the bandwidth required will depend on the number of simultaneous students in an exam multiplied by the size of the data they are accessing. For example, 200 students viewing a page with a 5Mb PDF file will generate 1Gb of network traffic. If this is going into one computer lab then if might be necessary to investigate the speed rating of the switches and other gear which serves that lab. A way to partly mitigate against large spikes is to include larger files within the middle of an exam so that not all the students will be requesting the file at the same time as they work through the exam at their own rates.
- Storage - the Rogo application has quite modest storage needs, the main requirement will be the amount of media uploaded with each question. Images are usually not too large but attached PDF files, audio and video formats can take up quite a bit of space.
Platform Configuration
Rogō should run on any LAMP stack without modification however there are some configuration task which need to be undertaken to ensure smooth operation under load.
Installation
Extract Rogō into the web root and visit 'https://[YOUR_HOST_NAME]/install/index.php'. This will check your installation and create the appropriate databases and users.
Users using the development branch of Rogo will also need to run composer to install additional libraries:
cd /path_to_rogo_root_directory
php composer.phar install
--no-dev
Rogō Configuration
Rogō main configuration file is in /config/config.inc.php – This holds system wide setting for your installation.
Known Issues
- Rogo uses a large number of prepared SQL statements, MySQL before version 5.1 does not cache prepared statements. Using MySQL version grater than 5.1 is highly recommended for large cohorts.
- DO NOT USE Apache Alias for the rogo directory as this will break things, it looks like a subdirectory installation but doesnt work as the apache document root is not related to the path of the php files.