The main problem in Moodle is that it uses so many resources, mainly CPU and Database calls. I think it is because it constructs each web page dynamically, that is, it makes lots of calls to the database and builts the whole page each time any user uses it.
This overload can be slightly reduced using cache systems on PHP (such as PHP Accelerator) and the Database (such as the cache in MySQL 4.x), but anywhere they still are a big problem. Many Moodle sites have been banned from their hosting services because of this system overload.
A good solution to this could be making the Moodle site and courses static for most users. I mean, any course would be dynamic for the course designers or teachers, but once they make their changes, they would become static HTML pages for students (who make nearly all of the page hits). The only things that would keep dynamic would be the activity modules themselves (such as forum, quizzes, etc.).
This solution has been adopted and is successfully working in one of the 2 most important commercial e-learning platforms in the market: WebCT, and it works pretty well.
I think it would be a great idea to try to make Modle work this way, since it would become a much more scalable system. What do you think?
In reply to David Delgado
Re: Proposal to make Moodle use less resources and be faster
by Tom Murdock -
But everything is interactive. When students add something, the pages change for everyone (new forums, new recent activity, etc.). Wouldn't it take more time to convert and cache?
-Clueless in Baltimore
-Clueless in Baltimore
In reply to Tom Murdock
Re: Proposal to make Moodle use less resources and be faster
by David Delgado -
Just having the main Moodle site web page and the home page in any course static (HTML), would safe lots of CPU and database calls. Also, the main pages of the activity modules could be static once they are defined by the teacher.
The "conversion" (creation) of the dynamic web pages to static ones is just made once by the teacher. It would happen anytime the teacher makes a couple of modifications on the course and wants to make them avaliable to students.
So, the "conversion" process happens once, just for the teacher, and the resulting static, fast, pages are used everytime by lots of students.
It is not my own idea, as I have told you, it works perfectly in WebCT and I remember that it made an excelent use of the computer resources. Martin must know about this, since he was a WebCT admin, as I was.
The "conversion" (creation) of the dynamic web pages to static ones is just made once by the teacher. It would happen anytime the teacher makes a couple of modifications on the course and wants to make them avaliable to students.
So, the "conversion" process happens once, just for the teacher, and the resulting static, fast, pages are used everytime by lots of students.
It is not my own idea, as I have told you, it works perfectly in WebCT and I remember that it made an excelent use of the computer resources. Martin must know about this, since he was a WebCT admin, as I was.
In reply to David Delgado
Re: Proposal to make Moodle use less resources and be faster
by Tom Murdock -
Thanks for explaining the concept!
Here is what I was confused about regarding the difference between WebCT, Blackboard, and Moodle.
Let's say I modify a couple activities in my course. Would the course view be one that is also cached? (It seems the course view is probably the page hit most often).
My concern is that the course view also includes the "recent activity box" (one of the defining elements of Moodle).
Since it is triggered by student activity, wouldn't the teacher or admin have to "visit" the site in order for the dynamic student activity to be made static?
If the main Moodle page were the one that was made static (the one with the course list and site news, etc.), I guess this would make sense to me. Unless, of course, you allow participants to reply to the main page (which I doubt many of us do).
-Tom
Here is what I was confused about regarding the difference between WebCT, Blackboard, and Moodle.
Let's say I modify a couple activities in my course. Would the course view be one that is also cached? (It seems the course view is probably the page hit most often).
My concern is that the course view also includes the "recent activity box" (one of the defining elements of Moodle).
Since it is triggered by student activity, wouldn't the teacher or admin have to "visit" the site in order for the dynamic student activity to be made static?
If the main Moodle page were the one that was made static (the one with the course list and site news, etc.), I guess this would make sense to me. Unless, of course, you allow participants to reply to the main page (which I doubt many of us do).
-Tom
In reply to David Delgado
Re: Proposal to make Moodle use less resources and be faster
by Martin Dougiamas -
David, I really like and appreciate your work, but you have got to watch this tendency towards "panic posting"
Firstly, what's this about *many* sites have been banned? I know of exactly one case, posted today, and that was by a $5 hosting company which has to fit hundreds of accounts on each of their servers - I'd love to see you try and run WebCT on an account like that!
Secondly, there is already caching in Moodle (for example the whole course outline is stored in processed form), and when this is combined with caching by PHP accelerator, ADOdb and MySQL 4 then the system is already doing exactly what you propose. The gains of this caching are not slight - they are huge (10-30 times)!
There is always room for some improvement (for example old forum posts could and will one day all be stored as HTML), but the overall possible gains are nowhere near as big as you are guessing. Chill out, dude.
Firstly, what's this about *many* sites have been banned? I know of exactly one case, posted today, and that was by a $5 hosting company which has to fit hundreds of accounts on each of their servers - I'd love to see you try and run WebCT on an account like that!
Secondly, there is already caching in Moodle (for example the whole course outline is stored in processed form), and when this is combined with caching by PHP accelerator, ADOdb and MySQL 4 then the system is already doing exactly what you propose. The gains of this caching are not slight - they are huge (10-30 times)!
There is always room for some improvement (for example old forum posts could and will one day all be stored as HTML), but the overall possible gains are nowhere near as big as you are guessing. Chill out, dude.
In reply to David Delgado
Re: Proposal to make Moodle use less resources and be faster
by Greg Barnett -
Since almost every page is customized for each user, and rightfully so, cacheing is not the answer.
While I do think that Moodle could be more efficient, just remember the aphorism "premature optimization is the root of all evil".
As the code evolves, improvements are being made. Even if some are stopgap hacks, such as some of the changes I've contributed with making certain variables in some functions "static", moodle performance is improving. Moodle is getting much better with creating proper database indexes, which has been a huge performance boost.
I would recommend to anyone putting together a serious moodle installation for anything other than testing to use dedicated servers (2, one for the database, one for the webserver) instead of shared hosting.
Whenever moodle gets too slow for me, I either move to better hardware, or start poking through the code looking for places to improve it.
While I do think that Moodle could be more efficient, just remember the aphorism "premature optimization is the root of all evil".
As the code evolves, improvements are being made. Even if some are stopgap hacks, such as some of the changes I've contributed with making certain variables in some functions "static", moodle performance is improving. Moodle is getting much better with creating proper database indexes, which has been a huge performance boost.
I would recommend to anyone putting together a serious moodle installation for anything other than testing to use dedicated servers (2, one for the database, one for the webserver) instead of shared hosting.
Whenever moodle gets too slow for me, I either move to better hardware, or start poking through the code looking for places to improve it.