Until the end of the academic year we had been running moodle 1.5 with no performance issues. We decided that during the school break we would upgrade to 1.8 for a few of the new features.
The features are great but hit us a lot on performance. Running 1.5 we often had over 50 users using the site with out even thinking about a performance hit. After upgrading to 1.8 with only 3 or 4 staff using the site as the students are on holiday we had to upgrade the VPN and are still getting extremely long page loads and high processor usage/server load.
I have read lots of issues about this on the moodle site and we are just curious how much of a priority the performance fixes are for the developers. There are a lot of people suggesting changes but after setting up a fresh install of the most current moodle and using a copy of our active data the performance of the moodle is not any better than ours.
We need to make a rash decision this week to either keep 1.8 or revert to 1.6. (Other versions performance stated below), we still have a copy of the DB before upgrading and haven’t made any huge changes after implementing 1.8 so this should be fine.
Are there any clues about what fixes are going to be implemented in the 1.9 release performance wise and is there an expected release date at all?
Are any other moodle users experiencing the same issues and considering reverting back to a previous version before the schools go back there is a heavy stream of users using the site again?
Testing results (1 request per second)
Moodle 1.6 - this seems to be very efficient, and 1 request per second is hardly noticeable on processor load on the web server. With regards to the database server I couldn't actually tell anything was running.
Moodle 1.7 - this gets a little less efficient, sitting the processor at around 10% with the same 1 request per second, again the database server has no load.
Moodle 1.8 - here is where we hit issues - With no data in the database, doing 1 request per second sits the CPU up at around 60%. The database server again isn't noticeably used.
As the database server is running on its own dedicated server, with high speed drives, lots of ram, and is well optimised for mysql we hardly ever see the load go above a few percent, therefore the tests being done on moodle may well have been doing 100's or 1000's of queries, but due to the setup they may have been being done so fast that it wasn't noticeable.
According to Moodle's documentation a rough guide to the number of users is 50 times the amount of ram in gig - the server I installed these on has 2GB of ram, so in theory should be able to cope with 100 users. I'm not sure how often they expect users to click links, but 1 click per user every 5-10 seconds isn't out of the question if they are navigating to a course - so going on my tests above, 100 users would be fine on Moodle 1.6, and probably 1.7, but on 1.8 I probably wouldn't want to run more than 30-40 users on these test results.
So going by this it looks like he problem is with the php itself and no the queries on the database we previously assumed.
Thanks for the quick reply.
I can’t say specifically what versions I was using but it was the latest 1.*.2+ releases available on 31/08/07 at about 5:50 GMT if that is any help, the testing was performed over the weekend. It wasn’t performed on any single page just generally clicking around the page but evenly to keep the tests fair. We were logged in as an admin user.
Hope that helps
So in the long run the performance issues being experienced by people aren’t to say an “issue” or something that will be looked into, it’s the upgrade process as it evolves.
So I guess in our case the best option would be to revert the moodle back down to 1.6 as none of the options implemented in the later version are of much use to us.
On the development track, yes, there is a fix coming for 1.9.x and/or 2.0 that takes performance back to v1.4/v1.5 levels but it is a huge unweildy patch.
I don't think we have lots of courses (180?) or lots of users (1675, between 500-600 unique logins per day). But our server grinds to a halt when a whole class (15-30) tries to download a file at the same time. It is very frustrating, especially coming from a 1.6.3 instance.
I applaud your efforts from the sidelines!
I'm a month behind (issues with Moodle.org no longer sending me digest messages) but we too have major speed issues since our upgrade to 1.8.1 but we are using apache not IIS.
I don't think our system is as big as yours and we have a quad processor machine running it and it still grinds to a standstill. Unfortunately the bridge back to version 1.5.2 was burned before we realised just how slow it was going to get.
If you have found one particular thing that got your systems moving again can you share that info as we are now under pressure to make it go faster.
- Set the variable allow_call_time_pass_reference = Off
- Changed Recycle work processes to 360 minutes instead of 1740, this should keep the memory usage from growing too great.
I am looking forward to performance improvements in 1.9, and perhaps we will be able to upgrade at the Christmas holiday. I will probably enlist the help of some computer lab instructors and maybe we can do some load testing prior to the rollout.
I have 1.6.2 running on an 800MHz PIII with 256MB ram with eAccelerator working like a champ. This machine continues to function (rebooted twice I think this past year for Ubuntu updates) continuously.
I have a second machine is coming online with significant hardware improvements (AMD X2 64 processor with 4 gig of ram and memory buffered SATA drives) once 1.8 can be tuned and bugs worked out with the migration (I feel these "bugs" are mine and have little to do specifically with Moodle). The new machine is also running eAccelerator. With the internal testing we are not seeing any performance lags as reported, but likewise we are not significantly loading the server either.
Hearing the patch is "wildly" for migration to 1.9 (2.0?), I wonder if the prudent solution is to simply wait for these improvements to materialize?