Geschwindigkeitsempfehlungen

Vorlage:Zum Übersetzen Moodle kann so konfiguriert werden, dass es sowohl für kleine als auch große Nutzerzahlen zuverlässig und schnell läuft. Die Faktoren, die die Geschwindigkeit von Moodle beeinflussen, sind im Wesentlichen dieselben wie für allgemeine PHP- und Datenbank-basierte Systeme. Wenn Sie Ihren Moodle-Server optimieren, konzentrieren Sie sich auf die Faktoren, die für die Nutzer/innen einen spürbaren Unterschied machen. Wenn Sie z.B. viel mehr Nutzer/innen haben, die sich nur durch Moodle durchklicken, als Nutzer/innen, die tatsächlich auf die Moodle-Datenbank zugreifen, dann versuchen Sie, die Webserver-Geschwindigkeit zu verbessern.

Basis-Benchmark

Bevor Sie mit der Optimierung Ihres Servers beginnen, benötigen Sie ein Basis-Benchmark Ihres Systems. Auf diesen Benchmark-Test beziehen sich alle Optimierungsbemühungen. Für Linux können Sie LBS verwenden, unter Windows können Sie den Performance Monitor nutzen. Erst wenn Sie über quantitative Daten verfügen, wie leistungsfähig Ihr System aktuell ist, können Sie feststellen, ob Ihre Anpassungen eine Verbesserung in der Geschwindigkeit bringen oder nicht.

Alle Bemühungen, die Geschwindigkeit zu verbessern, laufen darauf hinaus, den RAM (Caching) zu verwenden und die Zugriffe auf die Festplatte zu reduzieren. Insbesondere ist es wichtig, die Verwendung von SWAP zu vermeiden oder auf ein Minimum zu beschränken. Sobald Ihr System auf den SWAP ausweicht, benötigen Sie mehr RAM.

Die "Optimierungsreihenfolge" ist in der Regel folgende: Hauptspeicher (mehr RAM), Datenträger (schnellere Festplatten, verbesserte Festplattenkonfiguration), Prozessor (mehr und schneller).

Skalierbarkeit

Das Design von Moodle (mit klarer Trennung der Anwendungsschichten) ermöglicht skalierbare Systeme. Lesen Sie dazu auch den Artikel Große Installationen.

Große Installationen trennen normalerweise den Webserver und den Datenbank-Server und betreiben diese auf separaten physikalischen Servern. Für kleinere Installationen ist diese Trennung in der Regel nicht nötig.

Sie können für eine Moodle-Installation ein Load-Balancing betreiben, indem Sie z.B. mehr als einen Webserver einsetzen. Diese Webserver sollten auf dieselbe Moodle-Datenbank und dasselbe Moodle-Datenverzeichnis zugreifen. Ebenso kann die Datenbank auf einem Cluster von Servern liegen (z.B. auf einem MySQL Cluster) - das ist jedoch keine einfache Aufgabe, hierfür benötigen Sie Unterstützung durch Experten, z.B. durch einen Moodle-Partner.

Siehe auch folgende Diskussionsbeiträge im Kurs Using Moodle auf moodle.org:

• Moodle clustering
• Software load balancing
• TCP load balancing
• Installation for 3000 simultaneous users

Hardware-Konfiguration

Hinweis: Die schnellste und effektivste Möglichkeit, die Geschwindigkeit des Moodle-Servers zu erhöhen, ist das Bereitstellen von mehr RAM -so viel wie möglich (mindestens 4 GB). Mehr Speicher bedeutet weniger Swapping auf die Festplatte, und der Server kann mehr Nutzer/innen gleichzeitig bedienen.

• Verwenden Sie die besten Prozessoren und mehrere Prozessoren. Testen Sie mit dem CPU Benchmark Tool, ob Sie damit Verbesserungen in der Geschwindigkeit erreichen.
• Wenn ie es sich leisten können, verwenden Sie SCSI Festplatten statt SATA Festplatten. SATA Festplattenbrauchen mehr Zugriffe auf die CPU, während SCSI Festplatten eigene intergrierte Prozessoren haben. Wenn Sie SATA Festplatten haben, stellen Sie sicher, dass die Festplatten und das Motherboard NCQ (Native Command Queuing) unterstützen.
• Kaufen Sie Festplatten, die eringe Suchzeiten (seek time) haben. Dadurch verbessert sich die Gesamtgeschwindigkeit Ihres Systems, insebsondere wenn Sie auf Moodle-Berichte zugreifen.
• Konfigurieren Sie den SWAP in der richtigen Größe. The general advice is to set it to 4 x physical RAM.
• Verwenden Sie ein RAID System. Es gibt viele verschiedene Konfigurationsmöglichkeiten für ein RAID System, wir empfehlen folgende Konfiguration:
  • Installieren Sie einen Hardware RAID Controller (falls möglich)
  • Die Platten für das Betriebssystem und den SWAP konfigurieren Sie als RAID-1.
  • Moodle, den Web-Server und den Datenbank-Server konfigurieren Sie auf einer oder mehreren anderen Festplatten als RAID-5.
• Nutzen Sie ein Gigabit Ethernet. Das ist insbesondere dann wichtig, wenn Sie den Web-Server und den Datenbank-Server auf verschiedenen Servern laufen haben.
• Prüfen Sie die Einstellungen auf Ihrer Netzwerk-Karte. Sie können evtl. Verbesserungen erreichen, wenn Sie die Nutzung des Buffers und der Transmit/Receive Descriptoren erhöhen und wenn Sie die Berechnung der TCP Checksumme auf die Karte auslagern, statt auf das Betriebssystem.
• Lesen Sie diesen Diskussionsbeitrag Case Study - eine Studie zu einem Server-Stress-test mit 300 Nutzer/innen.
• Lesen Sie diesen Beitrag accompanying report - Bericht über Netzwerk-Traffic und Serverlast.
• Siehe moodle.org Konfiguration.
• Siehe [1] - SFSU Präsentation von Educause (unter Verwendung von VMWare)

Betriebssystem

• Sie können für den Moodle-Server folgende Betriebssysteme verwenden: Linux verwenden (empfohlen), Unix, Windows oder Mac OS X.
• Linux und Unix brauchen generell weniger Speicher als Mac OS X oder Windows Servers. Darüber hinaus hat Linux keine Lizenzgebühren. Wenn Sie eine große Anzahl von Prozessoren mit SMP haben, dann können Sie auch ein hoch angepasstes Betriebssystem verwenden, z.B. Solaris.
• Beachten Sie die Optimierungsempfehlungen Ihres Betriebssystems und des Herstellers.
  • Für Linux lesen Sie die Informationen auf dieser Linux Performance Team Website.
  • Für Linux testen Sie den Befehl hdparm, z.B. können Sie den Befehl hdparm -m16 -d1 verwenden, um Lesen und Schreiben auf mehreren Sektoren und DMA zu aktivieren. Mounten Sie Festplatten mit den Optionen async und noatime.
  • Für Windows konfigurieren Sie den Server so, dass er für Netzwerk-Applikationen optimiert ist (Systemsteuerung, Netzwerkverbindungen, LAN-Verbindungen, Eigenschaften, Datei & Drucker Sharing für Microsoft Netzwerke, Eigenschaften, Optimierung). Sie können auch auf der Microsoft TechNet Website nach Optimierungsanleitungen suchen.

Webserver-Geschwindigkeit

Wenn Sie Firefox und die Firebug Erweiterung installieren, können Sie die Zeiten beobachten, die es dauert einzelne Komponenten einer Moodle-Seite zu laden. Die Yslow Erweiterung bewertet Ihre Seite in Bezug auf die 14 Regeln für schnelle Webseiten. Siehe auch Best Practices for Speeding Up Your Web Site, für schnelles Laden von Webseiten.

PHP-Geschwindigkeit

• Wir empfehlen dringend, einen PHP-Accelerator zu verwenden, um die CPU-Last zu reduzieren, z.B. APC, PHPA, Xcache, WinCache oder eAccelerator. Achten Sie darauf, dass der PHP-Accelerator für die PHP-Version Ihres Moodle-Servers funktioniert. Beachten Sie auch, dass Turck MMCache nicht mehr weiterentwickelt wird und Fehler bei PHP 5 verursachen kann.
• Verbesserungen bei Lese-/Schreibzugriffen können Sie erzielen, wenn Sie gecachte PHP-Seiten in einem TMPFS-Dateisystem ablegen. Beachten Sie jedoch, dass die Cache-Inhalte verloren gehen, wenn Ihr Server von einem Stromausfall betroffen ist oder wenn Sie den Server neu starten.
• Die PHP-Geschwindigkeit verbessert sich, wenn PHP als ein Apache/IIS ISAPI Modul installiert ist (und nicht als CGI).
• Prügen Sie die PHP-Einstellung memory_limit in der PHP-Konfigurationsdatei php.ini. Für PHP 5 werden 128 MB empfohlen, siehe PHP 5.2.1 .
• Siehe auch PHP-Versionen für Moodle

Installationsanleitungen

• APC unter CentOS 5.x (linux)
• APC unter Debian (linux)
• MemCache Modul unter Debian (Apache2 und PHP5)
• Memcache unter CentOS 5.x (linux)
• eAccelerator unter CentOS 5.x (linux)
• Installing eAccelerator unter Ubuntu Server (linux)

Apache-Geschwindigkeit

• Wenn Sie Apache auf einem Windows-Server nutzen, verwenden Sie die Pakete der Apache Lounge, die eine bessere Geschwindigkeit und Stabilität haben als die offiziellen Apache-Download-Pakete. Beachten Sie jedoch, dass es sich dabei um inoffizielle Pakete handelt, die evtl. nicht so aktuell sind wie die offiziellen Apache-Pakete.
• Setzen Sie die Einstellung MaxClients Direktive gemäß der Formel (verwende nur 80% des verfügbaren Speichers, um Reserven zu haben):

  MaxClients = Verfügbarer Speicher * 80% / Maximaler Speicherbedarf der Apache-Prozesse

Der Speicherbedarf der Apache-Prozesse beträgt normalerweise 10MB, aber Moodle kann schnell bis zu 100MB pro Prozess benötigen. Als Faustregel können Sie den verfügbaren Speicher in MB durch 100 teilen, um einen konservativen Wert für die MaxClients zu erhalten. Sehr wahrscheinlich können Sie den Standardwert von 150 auf einem Moodle-Server nach unten anpassen. Um eine genauere Schätzung zu erhalten, geben Sie folgenden Befehl auf der Kommandozeile ein:

  #ps -ylC httpd --sort:rss

Wenn Sie den Wert für die MaxClients auf über 256 erhöhen, müssen Sie die Einstellung ServerLimit anpassen.

Achtung: Do not be tempted to set the value of MaxClients higher than your available memory as your server will consume more RAM than available and start to swap to disk.

• Consider reducing the number of modules that Apache loads in the httpd.conf file to the minumum necessary to reduce the memory needed.
• Use the latest version of Apache - Apache 2 has an improved memory model which reduces memory usage further.
• For Unix/Linux systems, consider lowering MaxRequestsPerChild in httpd.conf to as low as 20-30 (if you set it any lower the overhead of forking begins to outweigh the benefits).
• For a heavily loaded server, consider setting KeepAlive Off (do this only if your Moodle pages do not contain links to resources or uploaded images) or lowering the KeepAliveTimeout to between 2 and 5. The default is 15 (seconds) - the higher the value the more server processes will be kept waiting for possibly idle connections. A more accurate value for KeepAliveTimeout is obtained by observing how long it takes your users to download a page. After altering any of the KeepAlive variables, monitor your CPU utilization as there may be an additional overhead in initiating more worker processes/threads.
• As an alternative to using KeepAlive Off, consider setting-up a Reverse Proxy server infront of the Moodle server to cache HTML files with images. You can then return Apache to using keep-alives on the Moodle server.
• If you do not use a .htaccess file, set the AllowOverride variable to AllowOverride None to prevent .htaccess lookups.
• Set DirectoryIndex correctly so as to avoid content-negotiation. Here's an example from a production server:

DirectoryIndex index.php index.html index.htm

• Unless you are doing development work on the server, set ExtendedStatus Off and disable mod_info as well as mod_status.
• Leave HostnameLookups Off (as default) to reduce DNS latency.
• Consider reducing the value of TimeOut to between 30 to 60 (seconds).
• For the Options directive, avoid Options Multiviews as this performs a directory scan. To reduce disk I/O further use

Options -Indexes FollowSymLinks

• Caching (unsupported) - Please note that this kind of caching may create major problems during upgrades. Apache can be told to make pages load a lot faster by specifying that the browser should cache some various page elements such as images and reuse them from local memory rather than ask for them again every time a page is requested. How to do this varies slightly between OSes but there are two basic steps:

1. Install and enable mod_expires - refer to documentation or man pages
2. Add this code to the virtual server config file within the <directory> section for the root directory (or within the .htaccess file if AllowOverrides is On):

<IfModule mod_expires.c>
 ExpiresActive On
 ExpiresDefault "access plus 1 seconds"
 ExpiresByType text/html "access plus 1 seconds"
 ExpiresByType image/gif "access plus 1 week"
 ExpiresByType image/jpeg "access plus 1 week"
 ExpiresByType image/png "access plus 1 week"
 ExpiresByType text/css "access plus 1 week"
 ExpiresByType text/javascript "access plus 1 week"
 ExpiresByType application/x-javascript "access plus 1 week"
 ExpiresByType text/xml "access plus 1 seconds"
</IfModule>

The effect is to make everything stay in the cache except HTML and XML, which change dynamically. It's possible to gain a several hundred percent decrease in load times this way. Adjust the cache times according to how often your images etc change.

• Compression reduces response times by reducing the size of the HTTP response

1. Install and enable mod_deflate - refer to documentation or man pages
2. Add this code to the virtual server config file within the <directory> section for the root directory (or within the .htaccess file if AllowOverrides is On):

<ifModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/xml
</ifmodule>

More info: www.metaskills.net

IIS-Geschwindigkeit

All alter this location in the registry:

HKLM\SYSTEM\CurrentControlSet\Services\Inetinfo\Parameters\

• The equivalent to KeepAliveTimeout is ListenBackLog (IIS - registry location is HKLM\ SYSTEM\ CurrentControlSet\ Services\ Inetinfo\ Parameters). Set this to between 2 to 5.
• Change the MemCacheSize value to adjust the amount of memory (Mb) that IIS will use for its file cache (50% of available memory by default).
• Change the MaxCachedFileSize to adjust the maximum size of a file cached in the file cache in bytes. Default is 262,144 (256K).
• Create a new DWORD called ObjectCacheTTL to change the length of time (in milliseconds) that objects in the cache are held in memory. Default is 30,000 milliseconds (30 seconds).

Lighttpd, NginX and Cherokee performance

You can increase server performance by using a light-weight webserver like lighttpd, nginx or cherokee in combination with PHP in FastCGI-mode. Lighttpd was originally created as a proof-of-concept[2] to address the C10k problem and while primarily recommended for memory-limited servers, its design origins and asynchronous-IO model make it a suitable and proven[3] alternative HTTP server for high-load websites and web apps, including Moodle. See the MoodleDocs Lighttpd page for additional information, configuration example and links.

Alternatively, both lighttpd and nginx are capable of performing as a load-balancer and/or reverse-proxy to alleviate load on back-end servers[4], providing benefit without requiring an actual software change on existing servers.

Do note that these are likely to be the least tested server environments of all particularly if you are using advanced features such as web services and/or Moodle Networking. They are probably best considered for heavily used Moodle sites with relatively simple configurations.

Datenbank-Geschwindigkeit

Moodle contains a script which will display some key database performance statistics from the ADOdb performance monitor. Run the script in your browser as in the following example:

http://www.mymoodle.com/admin/dbperformance.php

Use the data displayed as a guide to tune and improve the performance of your database server.

MySQL-Geschwindigkeit

The following are MySQL specific settings which can be adjusted for better performance in your my.cnf (my.ini in Windows). The file contains a list of settings and their values. To see the current values use these commands

SHOW STATUS;
SHOW VARIABLES; 

Important: You must make backups of your database before attempting to change any MySQL server configuration. After any change to the my.cnf, restart mysqld.

If you are able, the MySQLTuner tool can be run against your MySQL server and will calculate appropriate configuration values for most of the following settings based on your current load, status and variables automatically.

• Enable the query cache with

query_cache_type = 1. 

For most Moodle installs, set the following:

query_cache_size = 36M 
query_cache_min_res_unit = 2K. 

The query cache will improve performance if you are doing few updates on the database.

• Set the table cache correctly. For Moodle 1.6 set

table_cache = 256 #(table_open_cache in MySQL > 5.1.2)

(min), and for Moodle 1.7 set

table_cache = 512 #(table_open_cache in MySQL > 5.1.2)

(min). The table cache is used by all threads (connections), so monitor the value of opened_tables to further adjust - if opened_tables > 3 * table_cache(table_open_cache in MySQL > 5.1.2) then increase table_cache upto your OS limit. Note also that the figure for table_cache will also change depending on the number of modules and plugins you have installed. Find the number for your server by executing the mysql statement below. Look at the number returned and set table_cache to this value.

mysql>SELECT COUNT(table_name) FROM information_schema.tables WHERE table_schema='yourmoodledbname';

• Set the thread cache correctly. Adjust the value so that your thread cache utilization is as close to 100% as possible by this formula:

thread cache utilization (%) = (threads_created / connections) * 100

• The key buffer can improve the access speed to Moodle's SELECT queries. The correct size depends on the size of the index files (.myi) and in Moodle 1.6 or later (without any additional modules and plugins), the recommendation for this value is key_buffer_size = 32M. Ideally you want the database to be reading once from the disk for every 100 requests so monitor that the value is suitable for your install by adjusting the value of key_buffer_size so that the following formulas are true:

key_read / key_read_requests < 0.01
key_write / key_write_requests <= 1.0

• Set the maximum number of connections so that your users will not see a "Too many connections" message. Be careful that this may have an impact on the total memory used. MySQL connections usually last for milliseconds, so it is unusual even for a heavily loaded server for this value to be over 200.
• Manage high burst activity. If your Moodle install uses a lot of quizzes and you are experiencing performance problems (check by monitoring the value of threads_connected - it should not be rising) consider increasing the value of back_log.
• Optimize your tables weekly and after upgrading Moodle. It is good practice to also optimize your tables after performing a large data deletion exercise, e.g. at the end of your semester or academic year. This will ensure that index files are up to date. Backup your database first and then use:

mysql>CHECK TABLE mdl_tablename;
mysql>OPTIMIZE TABLE mdl_tablename;

The common tables in Moodle to check are mdl_course_sections, mdl_forum_posts, mdl_log and mdl_sessions (if using dbsessions). Any errors need to be corrected using REPAIR TABLE (see the MySQL manual and this forum script).

• Maintain the key distribution. Every month or so it is a good idea to stop the mysql server and run these myisamchk commands.

#myisamchk -a -S /pathtomysql/data/moodledir/*.MYI

Warning: You must stop the mysql database process (mysqld) before running any myisamchk command. If you do not, you risk data loss.

• Reduce the number of temporary tables saved to disk. Check this with the created_tmp_disk_tables value. If this is relatively large (>5%) increase tmp_table_size until you see a reduction. Note that this will have an impact on RAM usage.

PostgreSQL-Geschwindigkeit

There are some good papers around on tuning PostgreSQL, and Moodle's case does not seem to be different to the general case.

The first thing to recognise is that if you really need to worry about tuning you should be using a separate machine for the database server. If you are not using a separate machine then the answers to many performance questions are substantially muddied by the memory requirements of the rest of the application.

You should probably enable autovacuum, unless you know what you are doing. Many e-learning sites have predictable periods of low use, so disabling autovacuum and running a specific vacuum at those times can be a good option. Or perhaps leave autovacuum running but do a full vacuum weekly in a quiet period.

Set shared_buffers to something reasonable. For versions up to 8.1 my testing has shown that peak performance is almost always obtained with buffers < 10000, so if you are using such a version, and have more than 512M of RAM just set shared_buffers to 10,000 (8MB).

The buffer management had a big overhaul in 8.2 and "reasonable" is now a much larger number. I have not conducted performance tests with 8.2, but the recommendations from others are generally that you should now scale shared_buffers much more with memory and may continue to reap benefits even up to values like 100,000 (80MB). Consider using 1-2% of system RAM.

PostgreSQL will also assume that the operating system is caching its files, so setting effective_cache_size to a reasonable value is also a good idea. A reasonable value will usually be (total RAM - RAM in use by programs). If you are running Linux and leave the system running for a day or two you can look at 'free' and under the 'cached' column you will see what it currently is. Consider taking that number (which is kB) and dividing it by 10 (i.e. allow 20% for other programs cache needs and then divide by 8 to get pages). If you are not using a dedicated database server you will need to decrease that value to account for usage by other programs.

Some other useful parameters that can have positive effects, and the values I would typically set them to on a machine with 4G RAM, are:

work_mem = 10240

That's 10M of RAM to use instead of on-disk sorting and so forth. That can give a big speed increase, but it is per connection and 200 connections * 10M is 2G, so it can theoretically chew up a lot of RAM.

maintenance_work_mem = 163840

That's 160M of RAM which will be used by (e.g.) VACUUM, index rebuild, cluster and so forth. This should only be used periodically and should be freed when those processes exit, so I believe it is well worth while.

max_fsm_pages = 100000
max_fsm_relations = 5000

These are used to hold the free-space map, and if they are too small you will see performance degradation after the database has been operating for some time. The exact numbers to set can be gleaned from the output of VACUUM VERBOSE, which prints the required FSM pages at the end of it's run. The 5x increase seems to be useful for a Moodle installation, from experience.

wal_buffers = 64

These buffers are used for the write-ahead log, and there have been a number of reports on the PostgreSQL mailing lists of improvement from this level of increase.

This is a little out of date now (version 8.0) but still worth a read: http://www.powerpostgresql.com/Docs

And there is lots of good stuff here as well: http://www.varlena.com/GeneralBits/Tidbits/index.php

Based on Andrew McMillan's post at Tuning PostgreSQL forum thread.

Geschwindigkeitshinweise zu anderen Datenbanksystemen

• Consider using a distributed cacheing system like memcached but note that memcached does not have any security features so it should be used behind a firewall.
• Consider using PostgreSQL. See Arguments in favour of PostgreSQL and how to migrate from MySQL to PostgreSQL (forum discussion).
• Try increasing the database connection lifetime
• General advice on tuning MySQL parameters (advice from the MySQL manual)
• InnoDB performance optimization taken from the MySQL performance blog site.

Geschwindigkeit der verschiedenen Moodle-Module

Moodle's activity modules, filters, and other plugins can be activated/deactivated. If necessary, you may wish to deactivate some features (such as chat) if not required - but this isn't necessary. Some notes on the performance of certain modules:

• The Chat module is said to be a hog in terms of frequent HTTP requests to the main server. This can be reduced by setting the module to use Streamed updates, or, if you're using a Unix-based webserver, by running the chat in daemon mode. When using the Chat module use the configuration settings to tune for your expected load. Pay particular attention to the chat_old_ping and chat_refresh parameters as these can have greatest impact on server load.
• The Quiz module is known to stretch database performance. Try to optimise your database server by tuning. See for a brief report on performance for 55 students simultaneously using quizzes
  • See this Case Study for an extensive server stress test with 300 quiz users.[5] And this accompanying report on network traffic and server loads. [6]
• The Moodle Cron task is triggered by calling the script cron.php. If this is called over HTTP (e.g. using wget or curl) it can take a large amount of memory on large installations. If it is called by directly invoking the php command (e.g. php -f /path/to/moodle/directory/admin/cron.php) efficiency can be much improved.
• The Recent activities block is consuming to much resources if you have huge number of records mdl_log. this is being tested to optimize the SQL query.

Bildoptimierung in Moodle

The base images delivered in the original Moodle distribution package provide unoptimized graphics, most of which can benefit from lossless recompression utilizing optipng for PNGs, gifsicle for GIFs and jpegoptim for JPGs. Optimized graphics transfer faster and provide a faster perceived response for clients[7], especially distance learners. The following example will recursively optimize (without any loss of quality) all the graphics and image files included in a base Moodle installation directory on a server with the above commands installed and available.

find /example/directory/moodle-1.9 -iname *.png -exec optipng -o7 {} \;
find /example/directory/moodle-1.9 -iname *.gif -exec gifsicle -O2 -b {} \;
find /example/directory/moodle-1.9 -iname *.jpg -exec jpegoptim -p {} \;

Both optipng and gifsicle are provided in the base repositories of most newer Linux distributions; jpegoptim must be downloaded and installed manually.

Siehe auch

• Hardware and Performance - Diskussionsforum im Kurs Using Moodle auf moodle.org

Diskussionsbeiträge im Kurs Using Moodle auf moodle.org:

• Performance woes!
• Performance perspectives - a little script
• Comments on planned server hardware
• Moodle performance in a pil by Martin Langhoff