Moodle performance 1.9 versus 2.x (25% drop)

Moodle performance 1.9 versus 2.x (25% drop)

by Rex Lorenzo -
Number of replies: 35

I attended the Moodle.org developer meeting this week and it was mentioned by Martin D. that very large sites were reporting a 25% performance drop in using Moodle 2.x versus Moodle 1.9.

You can listen to the meeting recording at http://docs.moodle.org/dev/Developer_meeting_May_2012 at 1:20:44 timestamp.

Now, we are going to be deploying Moodle 2.2 in a month and this is the first time we heard about a significant performance drop between Moodle 1.9 and 2.x. Does anyone have more information on what Martin stated?

My questions are:

  1. What is defined as a "very large site"? Like, what is the breakpoint in which performance starts to degrade. (e.g. we are running 2k sites with ~20k students)
  2. In what areas are these large sites experiencing a bottleneck? Was it the web server, database, or file system?
  3. Does anyone have any contacts for these "very large sites"? I would like to contact them to see what their hardware setup is like and how they dealt with the performance drop
Average of ratings: Useful (1)
In reply to Rex Lorenzo

Re: Moodle performance 1.9 versus 2.x (25% drop)

by ben reynolds -

This is just a "me too" response in order to follow this discussion.

Average of ratings: -
In reply to Rex Lorenzo

Re: Moodle performance 1.9 versus 2.x (25% drop)

by Derek Chirnside -

One early definative post is this:

http://moodle.org/mod/forum/discuss.php?d=162045, but AFAIK no follow up has been done.

And I recall jmeter being mentioned, this from Google: http://www.moodlenews.com/2010/tech-tip-how-to-test-your-moodle-install-using-jmeter-migheille/

I've seen quite a difference in server tweaks, but I know nothng about the details.

And I presume you do know that it is not total students but some metric like simultaneous page requests (someone else can tweak the jargon)  never be in a class and say "OK, guys, start the Test now".  Tell them: "read this page.  When you are ready after that, start".  But that's pretty random.

I'm assuming Martin means "On the same hardware with the same RAM" maybe?

-Derek

Average of ratings: -
In reply to Derek Chirnside

Re: Moodle performance 1.9 versus 2.x (25% drop)

by Rex Lorenzo -

My take on Martin's comment was that Moodle 2 performance was okay compared to M19, but at a certain point Moodle 2 drastically slows down on heavy load. Was my understanding wrong?

Average of ratings: -
In reply to Rex Lorenzo

Re: Moodle performance 1.9 versus 2.x (25% drop)

by sam marshall -
Picture of Core developers Picture of Peer reviewers Picture of Plugin developers

Previous experiments initially showed rather more than a 25% performance drop between 1.9 and 2.0. Some people were reporting between a factor of 2 (50% drop) and 3 (67% drop). This matches our initial testing (before we upgraded) via jmeter load tests.

We moved to new hardware for our VLE2 platform and did not transfer all our load across at once, so for both those reasons we aren't able to quantify the drop with regard to live usage.

After that we saw worsened performance in Moodle 2.2 compared to 2.1 (that may have been the 25% drop reported?) but this was restored after adding a new index that Postgres needed on a certain field (which is included in Moodle 2.3 at least, forget the details).

On our current hardware, we do not have any bottlenecks and are not approaching hardware capacity. (We still haven't moved all our usage over to it, though.) Moodle 2.x runs perfectly well on it.

In summary, if you think you are near the performance limits of your current hardware on 1.9, I think you should probably plan to upgrade hardware at the same time as moving to 2.x, especially if you plan a 'big bang' move.

Just my opinion and I should note that I'm only reporting this experience - I am not part of the server/infrastructure team so none of this is actually my job, i.e. it is second-hand information.

--sam

Average of ratings: Useful (1)
In reply to Rex Lorenzo

Re: Moodle performance 1.9 versus 2.x (25% drop)

by Rosario Carcò -

Unfortunately I can start my test only after being able to clone my production server onto a second server, then upgrade this one to 2.x so as being able to produce the new backup-zip-files I will finally restore on a fresh installed THIRD Moodle 2.x server.

This might take place in a few months, July, August, September or so. And I should take a big big decision to continue with mySQL or switch over to PostgreSQL.

Due to different bad news I am still keeping my production server on Moodle 1.9 (5'500 courses, 14'200 users)

Rosario

Average of ratings: -
In reply to Rex Lorenzo

Re: Moodle performance 1.9 versus 2.x (25% drop)

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

It's a very rough number, simply because of the number of factors involved.  The number came from two estimates I got from two different sites which are very large, one was Open University (see Sam Marshall's response in this discussion too, he's also from OU).

A lot of what we did in Moodle 2.x was to make things faster.  The themes for example have heavily optimised caching.  Database access was streamlined, indexes improved.  Bottlenecks and memory hogs in cron were removed, etc.  On the other hand Moodle 2.x does a lot more stuff and has a lot more features.

Factors that would affect any estimate like this:

  • Number of users / courses / activities
  • Type and configuration of hardware
  • Type and configiration of database/OS
  • Number/type of integrations with other systems
  • Caching systems
  • Config settings for everything
  • Distribution of user load
  • Types of activities used
  • etc

All of this can not boil down to any particular number.   Still it worries me to hear any reports like this from our friends and all I meant to say in the meeting was that we plan to focus on peformance and make as many gains as we can.  We appreciate help from all developers in this.

If you have a big site, there is no substitute for doing your own testing on a development site that is as close as possible to your production site - re-evaluate all the parameters and PLAN FOR FUTURE GROWTH because student usage does tend to increase over time.  Turn off features you don't need.  Experiment with caching settings.  You may need more hardware - this is just a reality.  Moodle 2 is a different beast and assumptions from Moodle 1 will not always apply.

Average of ratings: Useful (2)
In reply to Martin Dougiamas

Re: Moodle performance 1.9 versus 2.x (25% drop)

by Gerard Arthus -

Martin,

 

This should not be unexpected. They took a system which was working perfectly well and instead of fixing the problems, changed a lot and actually made things worse, depending on what your usage of Moodle was like. I for one, did not need all of the bells and whistles, and liked the old file system much better. There should be two Moodles; one simple and sleek version and another for the users of smart-phones who like a lot of endless features which do not really address the educational needs of the students in my classes. A CMS should make my life easier, not slow things down and overly complicate it. I use both versions of Moodle and can emphatically say that while 2.x may be better as far as features might go, 1.9x is much better as far as usability. After all what should the main function of a tool be, if not to optimize our usage. So now we have a Moodle 2.x which is bloated with a good number of features which may or may not be useful and is slower to boot. Is this someone's idea of progress.

 

Gerry

Average of ratings: Useful (1)
In reply to Gerard Arthus

Re: Moodle performance 1.9 versus 2.x (25% drop)

by Derek Chirnside -

This sounds like 'deja vu': "One persons trivial is another mans critical"

In Moodle 2: think of

  • cloning activities
  • better text editor
  • themes (fo instance, have you seen the Awesome bar?)
  • file sharing between courses
  • Private files for learners
  • insert images into posts for learners
  • book as part of core
  • Conditional release

These are some of the things that save time and improve fiunctionality.

If you have a huge install, and a hacked system, then you may not need to upgrade, since you have hacked it.  Sadly these are the systems that are hard to upgrade.

But for some of us plebs who are stuck with hosting, then there are some good things in Moodle 2.

Just my 2c before I have a morning coffee.

-Derek

Average of ratings: -
In reply to Derek Chirnside

Re: Moodle performance 1.9 versus 2.x (25% drop)

by Gerard Arthus -

Derek,

 

This is exactly my point; I do not need or want any of the things on your list. In fact the mess they have made of the edit mode makes things even worse.

 

Gerry

Average of ratings: -
In reply to Gerard Arthus

Re: Moodle performance 1.9 versus 2.x (25% drop)

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

I'm glad you enjoy Moodle 1.9 - it's still there for you to use for as long as you like, as is Moodle 1.1.  smile

That said I think Moodle 2.3 is the easiest to use yet.

Average of ratings: -
In reply to Gerard Arthus

Re: Moodle performance 1.9 versus 2.x (25% drop)

by Janak Sodha -

Well said Derek.  Exactly my experience after using moodle 1 series for several years and now using moodle 2 series for 1 year.  The beauty of moodle 1.9 that everyone seems to have fogot is the moodledata file structure.  It was simple to quickly move contents into and out of the moodledata subfolders -  without using moodle!  To backup was simple.  Just backup the course as a empty shell (i.e. without files) to get a very small backup file thats easily stored.  To restore a course was also very simple.  It was total control and simple.  

I have three 1.9 moodle servers and one 2.4 which I will delete and replace with 1.9.  At the heart of moodle was simplicity, key feayures that allowed us educators to get on with teaching.  

In moodle 2, if you wanted to collate your lecture notes in a single folder - its a very painful process of searching through every single activity, and downloading the file hidden within this activity.  

Please if you need to add bells and whistles, add them to 1.9 but leave the file structure the same.

Janak

Average of ratings: Useful (1)
In reply to Martin Dougiamas

Re: Moodle performance 1.9 versus 2.x (25% drop)

by Marcus Green -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

Martin...

Have you got any specifics on things that can be turned off, or even things that might have been accidentally turned on (e.g. theme design mode) I run my moodle on web space purchased from my own pocket so planning for future growth is tricky smile. On the other hand I never have more than 19 students on the site at any one time....

Average of ratings: -
In reply to Marcus Green

Re: Moodle performance 1.9 versus 2.x (25% drop)

by Derek Chirnside -

I'll ask some specific question here: themes at category level, the docs still say this may being performance issues.

If you have a course with groups and groupings, how does that affect things?

What about Category level cohorts?

Is there any simple way to switch these on and off and compare performance.  What about installing Jmeter?  Is this a big deal, could we do some testing on our own systems without being a full on expert?  (Just curious)

-Derek

Average of ratings: -
In reply to Martin Dougiamas

Re: Moodle performance 1.9 versus 2.x (25% drop)

by Daniel Tran -

Hi Martin,

You stated: "Moodle 2 is a different beast and assumptions from Moodle 1 will not always apply".

Can you give us some examples?

UCLA is switching to Moodle 2.2 in about 2 weeks.  We are running on dedicated web server and database server.  The Web server has dual hex-core CPU with 48 GB RAM and database server has dual quad-core CPU with 32 GB RAM & fast disks.  The only caching we have is APC caching.

As far as optimization of the webserver and database server at the OS level, we were planning on using the same settings from our Moodle 1.9 environment which has been performing very well.

If this an appropriate approach, if not what do you recommend changing?

You mentioned caching systems.  Can you be more specific?

Thanks

Average of ratings: -
In reply to Daniel Tran

Re: Moodle performance 1.9 versus 2.x (25% drop)

by Gerard Arthus -

Martin,

This is not just about performance, it is also about usability. Moddle 2.x is much more complicated to use and unless one is really using all of these features, it is a time hog for the user with regard to creating and maintaining the course.

 

Gerry

Average of ratings: -
In reply to Gerard Arthus

Re: Moodle performance 1.9 versus 2.x (25% drop)

by Christopher O'Kelly -

Considering the post title "Re: Moodle performance 1.9 versus 2.x (25% drop)" I feel as though it IS, in fact, about performance and not at all about usability. Watched this thread grow over the past few days with some interest, as we are starting from moodle 2.x here and tips on performance are always appreciated. I have tried to keep out of it till now seeing as it isn't my thread but every time one of your replies to this thread lands in my inbox I fume a little inside at your determination to derail the thread.

I see that you are annoyed by what must appear to you as feature bloat. I can understand this. I personally feel that the MS Office products have succumbed to this over the years, so, I use 2003, which has the features I need and lacks a bunch of features I will never use. If you don't want the features in Moodle 2.x, why not use the version you do like (1.9)?

Is it possibly related to the support ending at some point in the future? Now if I spent a few hundred on MS Office and there was a security bug, I would expect a fix, whether my version was recent or not. Moodle is a different case entirely. It is free software, the fact that bugfixes are released for any version at all is a privilege, not a right.

Finally, Moodle is free because it is open source. One caveat of open source software is that it must respond to a wide range of user requirements. The fact that you or any individual do(es) not use some features does not mean that Moodle has failed by adding them. The demand existed, they met it. The beauty of open source is, if the features are truly that abhorrent to you, YOU can go change that for your installation. It will just take some work on your part. As far as I am concerned, if you want a product that is tailored for you and you want updates, fixes and support to be a right rather than a privilege, you go out and PURCHASE a piece of software (possibly with a support contract).

To me this is like complaining about how you bought a manual car for better fuel efficiency but you have to change gears all the time now.

 

/rant

Average of ratings: -
In reply to Gerard Arthus

Re: Moodle performance 1.9 versus 2.x (25% drop)

by Rex Lorenzo -

Gerry, you might want to check out the Clamp project (http://www.clamp-it.org/). It is based on Moodle, but customized by a group of liberal arts colleges to make it more usable.

But I do want to get the discussion back on track to how to improve performance. I would also be interested to know which modules/features should/can we turn off to improve things. Currently we turned off blogging and messaging.

Average of ratings: -
In reply to Rex Lorenzo

Re: Moodle performance 1.9 versus 2.x (25% drop)

by sam marshall -
Picture of Core developers Picture of Peer reviewers Picture of Plugin developers

Tip: If you can turn off the glossary filter (i.e. don't need it automatic links to glossary items), then you might want to experiment with turning off the text cache - see if that makes your page loads faster or slower. The text cache uses the database and can often make the page slower, except in cases where the glossary filter (which itself makes database requests) comes into play.

Messaging seems like it might be a performance drag, I don't know, because we turned it off too smile Not for performance reasons, we just don't like it.

Apart from that, all the 'make this slower' development/debugging options ship turned off by default so I don't really see the likelihood for large potential gains by changing system options.

We get typical load times [time for server to generate page] of about 300ms for the most important pages, such as course view. This doesn't seem to me to be especially poor performance. (Maybe Moodle 1.9 would have served the same pages given the same hardware in 100 or 150ms, but, well, so? Time moved on, we aren't using the same hardware, and 300ms is fine.) I think Moodle 2 can be configured to perform suitably.

It would be nice to see a new focus on performance from Moodle HQ (for example, let's say there were no new features at all in 2.4 and only back-end API changes to improve performance), but that's probably unrealistic. Here at the OU, there is a lot we could do ourselves to improve performance but we never have time to do any of it because new features are constantly demanded. I imagine it's the same all around the world.

--sam

Average of ratings: Useful (1)
In reply to sam marshall

Re: Moodle performance 1.9 versus 2.x (25% drop)

by Marcus Green -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

Sam, your wish may come true, according to the road map at

http://docs.moodle.org/dev/Roadmap

One of the targets for version 2.4 (aimed for Dec 2012) is

Performance - big focus on performance issues, including a "Moodle Universal Cache" (MUC) system

 

Average of ratings: Useful (2)
In reply to Marcus Green

Re: Moodle performance 1.9 versus 2.x (25% drop)

by Aaron Hockett -

Marcus,

I'm curious, how is this caching system going to interact with APC, xcache and Varnish?

We at Warner Pacific College are moving up from an older 1.9.4 install up to a 2.2.3 install.  In doing so we're also moving from a Windows WAMP stack (shudder) to a Ubuntu box with a slew of web server enhancements.  One of my chief concerns was that the end user did not notice a slow down and if anything, noticed a performance increase.  I've done this through Apache2 tweaking and the Varnish reverse proxy server which is working wonderfully. 

There really is a stigma (true or not) over the performance decrase in Moodle 2.x which I hope gets addressed in the future. [if it is warranted] smile

Average of ratings: -
In reply to Daniel Tran

Re: Moodle performance 1.9 versus 2.x (25% drop)

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

I suggest you start here and come back if you have more questions.  smile

   http://docs.moodle.org/22/en/Performance_recommendations

Average of ratings: -
In reply to Martin Dougiamas

Re: Moodle performance 1.9 versus 2.x (25% drop)

by Rex Lorenzo -

Under "Database performance" there is mention of a script called /admin/dbperformance.php, but that doesn't seem to exist anymore in 2.2 in either /admin, /admin/tool, or /report. That tool would seem to be very useful. What happened to it?

Also has this page been updated recently? It seems like it is a cobbled together list of notes.

But one thing that I did find interesting and useful in Moodle is built-in support for the profiling tool XHProf: http://docs.moodle.org/dev/Setting_up_xhprof_on_Moodle

It is very cool. From looking at some profiling runs, the main bottleneck I see usually the navigation block, especially when some rendering of the nodes call "clean_text", which invokes HTMLPurifier and it's heavy framework.

For most of my profile runs the "HTMLPurifier_Config::getAll" gets called a lot (e.g. 475 calls, 15% of request time). Might be worth looking into caching or have a single HTMLPurifier instance loaded and resued per page rendering. Or maybe that is already being done and I am misreading the results.

Or the navigation block can either

  1. Try not to call clean_text. Just "strip_tags" the node text.
  2. Do a lazy load and only render/fetch navigation nodes if the section is expanded by the user (will only speed up users with AJAX turned on in their profiles)
Average of ratings: -
In reply to Rex Lorenzo

Re: Moodle performance 1.9 versus 2.x (25% drop)

by David McCarthy -

We are developing a new business training service using Moodle. Our flagship course is nearly complete (there is only one other, very minor, course at present). This project has been 2 years in the making. We are running Moodle on a shared hosting account, so there's very little we can do to improve the performance (having followed hints & tips as far as I can), and I know nothing of Linux.

We moved to a bigger/faster hosting service last September to gain some more performance. We could do that again (and double our hosting costs again), but don't currently have the revenue.

We have a single user at the moment ... the course devloper ... and she reports 2.3.1 is slower than our previous 2.2.

We would welcome a release (2.4) which makes Moodle instrinsically faster - we may well need it when we get real students into the system.

Average of ratings: -
In reply to David McCarthy

Re: Moodle performance 1.9 versus 2.x (25% drop)

by Michael Penney -

Moodle 2 is slower. There is more going on under the hood that impacts performance on the one hand, and on the other hand the execellant and extensive work that Martin Langhoff et al. did on optimizing the 1.x series, has not be been done on 2.x. 

Moodle 2 performance can be greatly improved by server side optimization - non-Moodle specialists often don't/can't do this - on the one hand most hosting companies want to have a single build of their server to reduce costs, and on the other hand they usually won't have the research data (sites with 100k+ Moodle users, for example) test optimizations against. You have to make choices in optimization, for example what works best for  delivering HTML websites or Drupal may not be what is best for Moodle. If 90% of a company's revenue comes from hosting static HTML sites, they won't be able to afford to optimze their hosting platform for Moodle.

For example, where I used to work at Remote-Learner, we had (well RL still does, but I don' work there anymorewink) very large data sets to test optimizations on, a dedicated lab for testing, and a resulting highly optimized Moodle server configuration. Server configuration here meaning optimized SAN with specific hardware, Red Hat build, specific memory types, etc. It's very hard to find that on shared/commodity hosting, though I have seen some large universities (UCLA, for example) bring a similar level of effort to optimizing Moodle performance.

There are likely some improvements to be made in the software. I'd love to see core engage a Moodle Partner or large University client (you need a large dataset of users, courses (esp. LOTS of quizzes), and logs to test optimzations against) to do the same kind of software optimization work that was done on 1.x.  However best results will always come from a dedicated Moodle hosting provider with expert staff and a hardware/software stack specifically optimized for Moodle. 

Average of ratings: Useful (2)
In reply to Rex Lorenzo

There is no magic bullet..

by Dan Poltawski -
A few people on this thread seem to be looking for one specific setting to turn off to make all performance problems go away. Well, if it worked like that then we'd be concentrating our efforts on fixing those magic bullets! I'm afraid its not that simple and its often the combination of a number of different factors.

Without real data, its not always possible to spot particular bottlenecks. Its incredibly helpful to us if sites can share their findings with performance problems, particularly bottlenecks. Recently Netspot and the OU have shared a few issues they've found for example, enabling us to help plug those gaps.
Average of ratings: -
In reply to Dan Poltawski

Re: There is no magic bullet..

by Derek Chirnside -

I'm not sure I agree with you Dan, I don't see people asking for a magic bullet.  Not in this thread anyway, well except for Marcus, but he does describe himself as derranged.  We are jut trying to consider with current Moodle how interactions work with various settings of the server and Moodle.

For instance: stas on vs off, category themes on vs off, messaging on vs off etc. I've been interested over the years to pick up some of the ways you work with this: looking at the number of database queries, looking at caching, config and php.ini tweaks, various different themes, completion tracking on/off, and the aspect of optimisation of the indexing etc.

I know the work that went into 1.9, mainly out of Catalyst (AFAIK) with the tweaking of the database and all the optimisation work, and I also know how hard it is to do ths well. But surely it is possible to give some metrics: listing a few of the settings that do provide a litle more overhead, and otherds where it is minimal?

I've got one unaswered question in this thread: jmeter.  Is it for amateurs? I have this romantic view that you may do something, like switch category themes on, check jmeter somehow, and then disable category themes and repeat - and on this basis you may decide if you want the pain of slow or not. But this is a non-tech person wondering.  It may be far more complex.  I also know there are interactions: choose a particlar theme with a few particula blocks and thing are different wthout blocks

. . .  fun and games  . . .

-Derek

Average of ratings: Useful (2)
In reply to Derek Chirnside

Re: There is no magic bullet..

by Marcus Green -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

Promoting the use of JMeter seems an excellent and very practical idea.  I have played with it a little myself, creating a script "from scratch", so running someone elses pre-defined scripts should be fairly easy. I have mainly used it to teach the concept of software stress testing.

Average of ratings: -
In reply to Derek Chirnside

Re: There is no magic bullet..

by Dan Poltawski -

For instance: stas on vs off, category themes on vs off, messaging on vs off etc. I've been interested over the years to pick up some of the ways you work with this: looking at the number of database queries, looking at caching, config and php.ini tweaks, various different themes, completion tracking on/off, and the aspect of optimisation of the indexing etc.

The problem is that it's entirely site dependent, so general advice doesn't work for things like this. In the past I've worked with single Moodle sites with hundreds of thousands of users & thousands of courses to Moodle sites with 10 users & one course. Different settings affect Moodle sites in different ways.

To use a an entirely non-technical example, when I was working with high schools, messaging used to be a big concern because the students would use it a lot at break times (lunch) causing massive spikes in performance to chatty each other. But this has never been a problem in university sites I've worked with because the students are not restricted in the same way as school students, so they probably don't use Moodle to gossip & even if they do, it's not in spikes. That was not a problem because messaging was particularly performance heavy, more a factor of the environment.

Average of ratings: Useful (2)
In reply to Rex Lorenzo

Re: Moodle performance 1.9 versus 2.x (25% drop)

by Frankie Kam -
Picture of Plugin developers

Anyone with a report like this, 

"Moodle 2.2 runs fine on out side and we - our users and the IT department - are satisfied with the speed performance of Moodle 2.2 at our institution. 
We did the following to speed up or site access:
... (please provide these valuable tips, tweaks, optimised settings, loaded this theme, removed off mods, blocks, and filters that we didn't need to make the system lean, tweaked the server OS,)
And our specifications are .....Windows/Linux platform, caching info (e.g., Varnish, APC, eaccelerator, etc), server processor, RAM, number of uses, peak time concurrent users count, additional hardware, e.g., load balancer, etc. We're using a XYZ Internet connection with ABC Mbps speed incoming and outgoing, etc."

Anyone?

For the record, my production Moodle 1.9.15 site is running fine and well with NO speed problems. Max concurrent users is 19 to 22 students. As for my Moodle 2.2 test site, the pages do seem to load a bit slower - a couple of seconds longer to load compared to my Moodle 1.9.15, even if with the Theme Designer Mode turned off. I can't really compare the two, as they are used for different purposes, but I am very happy with my Moodle 1.9.15 site. Also both sites are eaccelerator enabled. My site's specs are below:

Distro Name CentOS release 5.8 (Final)
HARDWARE INFORMATION
Processors 2
Model Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz
CPU Speed 1.6 GHz
BUS Speed
Cache Size 3072 KB
Bogomips 11674.12

Average of ratings: -
In reply to Frankie Kam

Re: Moodle performance 1.9 versus 2.x (25% drop)

by Alex Walker -

I work for a large college in Scotland (our Moodle gets 3,000-5,000 visits a day), and we're quite happy with the way our Moodle performs. We have two dedicated servers, each with a 6-core processor and 48GB RAM. One holds our MySQL database, and the other runs our web app in Apache/PHP with APC enabled.

I use an excellent free tool called Siege to load test my Moodle servers (both live and development). You can set a script to run through a few things on your Moodle, such as logging in, browsing around and accessing a few forums and files. You can specify the number of simulated users, the time between page loads, and how long the siege lasts.

Here's a few tips from my experience of running our Moodle 2.2 site over the last year:

  • Not every slowdown is caused by excessive load. Web applications are complex things and there can be bottlenecks in a number of places.
  • Use a tool like Siege to load test your site. It'll warn you if pages are taking a long time to load, or failing completely.
  • When load testing, keep an eye on your server by running top and monitoring the system load and the number of processes (particularly apache/httpd and mysql).
  • If pages are slowing down and failing, but the system load isn't particularly high, there's probably a bottleneck in the number of Apache or MySQL connections. Tuning these is a dark art and there's a lot more to it than I could describe here.
  • Turn on the MySQL Slow Query log and see which queries are taking a long time.
  • There are MySQL tuning scripts out there. Leave your Moodle running for a few weeks under normal load, then run one against your MySQL server. They'll recommend fixes for bottlenecks, such as cache sizes.
  • Theme Designer mode really will slow your site down. Make sure it's off if you're not editing your theme.
  • Filters (such as the swear filter, LaTeX filter etc.) will slow your site down, as Moodle has to run them against every piece of text it displays.
  • The amount of memory an Apache process consumes depends on the number of enabled Apache modules. Comment out some Apache modules you don't use, and Apache will use less memory. You'll be able to run more Apache processes (and hence, get more simultaneous connections) if you get this right.
  • Don't go crazy with the maximum number of Apache processes. Setting them as high as you want isn't the answer. If too many run at the same time, you'll run out of memory and start using swap, and things will get a lot worse. Instead of running out of available connections, you'll run the entire server into the ground. There's a "right number" for your server that depends on the amount of available RAM and the amount of RAM each Apache process is consuming.
  • If top shows a high percentage of CPU usage as WA ('waiting for IO'), it's likely a disk latency issue. If your Moodle is running from network shares mounted on your server, watch out for this. If you have a lot of RAM, you probably want to make sure Linux is using some RAM as disk cache properly.
  • Don't worry about high RAM usage when your server isn't busy. Linux is good at knowing how much RAM is available, and making the best use of it. It'll cache frequently-accessed files from the disk in memory, to speed things up. It'll get rid of these if the RAM is really needed by something else. You can manually purge the disk cache, but there's not much point.
Average of ratings: Useful (4)
In reply to Alex Walker

Re: Moodle performance 1.9 versus 2.x (25% drop)

by Dan Poltawski -
Thanks for sharing Alex,

Just a word of warning about siege though.. It's a fairly blunt instrument, not simulating real users logging in & doing actions. This distinction is quite significant in moodle - an admin viewing the site front page when logged in is a world apart from a guest user (simulated with siege) viewing that page in terms of thr processing which goes on.
Average of ratings: -
In reply to Dan Poltawski

Re: Moodle performance 1.9 versus 2.x (25% drop)

by Alex Walker -

That's true. I don't think it pulls the on-page assets (images, JS, CSS etc.) down with it. Pointing it at intensive PHP scripts can be useful though.

With our original Moodle (1.9, much smaller scale, not very powerful server, initial pilot to see if we wanted to move from Blackboard), we found that 20 people hitting the 'My Moodle' page at once totally oblitterated our server. Siege was useful for looking into that problem.

Average of ratings: -