Moodle Sites - Scaling and Architecture

Moodle Sites - Scaling and Architecture

by Alan Dawson -
Number of replies: 5

Hi...

 

We are looking at our Moodle infrastructure and I wonder if people here could provide some specifications of their moodle setups ?

 

Do you separate front end moodle application from backend database server ?

 

If so how many and what specification in RAM and processers are in them ?

 

If not what specification of servers are you running ?

 

How many concurrent users do you serve ?

 

What sorts of load do you see on your servers ?

 

 

Thanks in advance

 

Alan Dawson

Average of ratings: -
In reply to Alan Dawson

Re: Moodle Sites - Scaling and Architecture

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
It might be helpful if you could give some clue as to the scale of installation you are thinking of.

Moodle sites can vary by many orders of magnitude and there are different approaches depending on your needs.

Taking a wild stab in the dark, if you turn out to be an average sort of FE college in the UK, think in terms of two good quality server boxes (in particular don't scrimp on the disk IO subsystems) with as much RAM as they will can use or will fit. One for the webserver one for the database. If you don't want lots of pain, don't use Windows!
In reply to Howard Miller

Re: Moodle Sites - Scaling and Architecture

by Alan Dawson -

Hi Howard

Sure.. I've just been tasked with one of the "how long is a bit of string" kind of questions, and rather than ask "what do I need to support 3000 users" I wondered what other groups and institutions were using.

the piece of string is...

"In event of the college being closed, what would we need to do to support as much online learning as possible."  To which I said we'd monitor the system, optimize and extra capacity as necessary, but that doesn't help people who need to set aside budgets etc..

The existing moodle is based in a VMware environment, with an iSCSI SAN, so we can increase the processing power and RAM easily.  We'd need to be careful locating the virtual servers in Vmware, so they didn't compete. Also adding another frontend would be easy.

--

Alan Dawson

In reply to Alan Dawson

Re: Moodle Sites - Scaling and Architecture

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
A lot of people these days are in love with VM and I can kind of see the appeal but it only works to a point. In the end you still have a metal box with some disks and some RAM in it and something like Moodle can quite easily consume that box and more besides.

So, I'm guessing that your Moodle take-up is relatively small at the moment but if it really takes off you might be looking at those multiple physical servers just for Moodle. You're doing it right though - start small, low risk and collect some data. You should be able to extrapolate and get a good idea of what you might need.

I am involved with a configuration of roughly ten times the number of users you mention and it runs on 12(!) big Sun boxes - for example.
In reply to Howard Miller

Re: Moodle Sites - Scaling and Architecture

by Martín Langhoff -

Have to agree with Howard - VMs are good for small workloads, but any taxing workload needs to run on bare metal (or on a sandboxing scheme that runs at bare metal speed like Solaris Zones).

Having said that, here's something that is worth considering: a lot of people using VMs split frontend (FE) and backend (BE) - the DB -, just because they can. And it's a huge mis-optimisation.

When you have Apache/PHP and MySQL/Pg on the same box, they can communicate via a socket (and make sure they do by not giving Moodle a host:port combo to connect to). This socket connection is extremely fast and low latency.

If you split things, you increase latency on every SQL connection, on every query. This means each HTTP request takes longer to serve, which means you might serve theoretically the same # per second (assuming the FE is the bottleneck) but you have more Apache/PHP processes waiting on the FE. This in turn means significantly more memory use in the FE, and a lot of processes there just anxiously waiting for their data from the BE.

So the FE/BE split is only recommended if you have several (real, physical) FE machines. And when you do it, you must work on the network throughput and latency between them.

In reply to Martín Langhoff

ตอบ: Re: Moodle Sites - Scaling and Architecture

by Panyarak Ngamsritragul -
Instead of investing a sandbox, is it possible to use the NFS ability of Unix or Linux system ?

What I am thinking is :

1. One Database back end machine, powerful enough. I do not think we need many Database servers as the work load of Database server is far lower than those of Front ends.

2. One specially high performance Front end running Apache server and NFS service.

3. Other Front end machines (as many as one wants) but share the moodledata area through NFS service of machine in 2. above.

I have yet to try this out... but comments from experienced users should be useful for our consideration. Thanks.