Ok,
so we are looking at more widespread adoption and usage of Moodle in the coming year... one of my main priorities is to make page load times 'responsive' so that the user experience is fluid.
On 1.9 ( we are running wamp, but other am interested in all stats..), what are expected/ normal / good page load times?
for:
- front page
- course page
- gradebook (assume 50 students, 30 assignments)
we are running APC, but the performance footer never reports the cache hit etc - though APC admin page reports about 98% at the moment.
At the moment I am finding in general the frontpage seems to take 2 secs to load, the course page can take between 0.5-2 secs, and the gradeook in teacher view is about 4-7 seconds. Performance does seem to vary between these amounts. I have followed the instructions in the wiki on performance (http://docs.moodle.org/en/Performance).
This is on a pretty light load, (about 20 students in a class using it at the same time). At times CPU seems to spike 100%, but only for brief moments, memory usage seems to be healthy.
So... any way to get it faster (would love sub-second load times consistently!)? or is this normal / good? What are other people's experiences?
no replies?
I am still left wondering what 'good' performance of moodle is generally perceived to be? I know it is dependent on configuration, hardware, and usage, but if anyone has some general ballpark figures to share - I am sure I am not the only one that would find it useful?
To put it in perspective - the performance docs talk about HOW to get better performance, but with no reference to actual performance stats...
so - if anyone is willing to share ballpark figures - I know it would help me (and I am sure others as well) know what performance to expect in general...
Lael
I am still left wondering what 'good' performance of moodle is generally perceived to be? I know it is dependent on configuration, hardware, and usage, but if anyone has some general ballpark figures to share - I am sure I am not the only one that would find it useful?
To put it in perspective - the performance docs talk about HOW to get better performance, but with no reference to actual performance stats...
so - if anyone is willing to share ballpark figures - I know it would help me (and I am sure others as well) know what performance to expect in general...
Lael
I'd agree with your original point that it's difficult to provide a comparison as everything depends on configuration issues. However, there *is* a value in providing a target/benchmark comparisons so that others can see what kinds of performance can be achieved. So, here's my contribution for a site that I've done some optimisation on 
.
Ken, wow, that is impressive!
Can you give an indication of the (broadly speaking) optimisations you did? Which ones gave you the largest improvement in speed?
If I am able to get those times... I will be quite happy - does the site sustain those speeds under load?
Can you give an indication of the (broadly speaking) optimisations you did? Which ones gave you the largest improvement in speed?
If I am able to get those times... I will be quite happy - does the site sustain those speeds under load?
Your main question was about performance tweaking in general ("any way to get it faster"). The Moodle Docs has some accumulated info on that at http://docs.moodle.org/en/Performance. As you see from that page, there are literally hundreds of different issues, big and small, to consider. Subsecond page generation times are possible, as Ken demonstrated.
Your page load times are maybe a bit slow on an "empty" server, but quite ok if there is load on the server. We have similar page loads times with "medium" load.
Your page load times are maybe a bit slow on an "empty" server, but quite ok if there is load on the server. We have similar page loads times with "medium" load.
Thanks Sam, I will take another look at the performance docs to see what I might look at next. What sort of optimisations returned the most impact for you?
You've done some/most of these already, but some of the bigger things we did were:
- installed eAccelerator
- added more memory to the main server (from 4 Gb first to 8 Gb and then to 10 Gb)
- made sure that MySQL query cache is on
- allocated more memory to MySQL now that we had some to spare
- noticed that our DB was missing some indexes and added them
- upgraded the PHP version, ended up with less memory taken per thread
- tweaked Apache settings, like the KeepAliveTimeout to 2 seconds
Thankyou, that is helpful.
Of course with generalities there are always caveats, but... have you found the cumulative effect of the smaller tweaks to have made a noticeable / pleasing impact on performance? (i guess that means noticeable to you, or the users.. )
Compared to the big optimizations, like adding memory and installing cache, the sum impact of the smaller tweaks is relatively small. But that isn't to say that it couldn't be big, if some of the smaller variables is too wrong for your environment.
You could do some tweaks to the mysql configuration to give it more ram to cache. Esp if you turn on query caching. These can help a lot.
Aside from that, if Linux is an option you will find that your Moodle runs a lot faster on the same server hardware over the WAMP setup.
How long these pages take to load is also a factor of what you have on them. The other thing we have noticed is that as you scale up such as by adding a seperate DB server, that you will see these page load times increase a bit on average during off-peak testing do to the latency of taking the DB requests out over the network, but that the application will scale better in terms of the number of concurrent users.
I would say that the numbers you have posted are reasonable performance wise in my experience, but that it is also possible to tweak a system to perform faster as well.
Aside from that, if Linux is an option you will find that your Moodle runs a lot faster on the same server hardware over the WAMP setup.
How long these pages take to load is also a factor of what you have on them. The other thing we have noticed is that as you scale up such as by adding a seperate DB server, that you will see these page load times increase a bit on average during off-peak testing do to the latency of taking the DB requests out over the network, but that the application will scale better in terms of the number of concurrent users.
I would say that the numbers you have posted are reasonable performance wise in my experience, but that it is also possible to tweak a system to perform faster as well.
Thanks Jonathon, I currently have query caching on as you suggest, with a fairly high hit rate (80-90% from memory). I might try increasing the amount of ram allocated as well.
I don't have experience with Linux, but have started experimenting to see what the learning curve will be. It seems manageable. Maintainability is a concern though.
ok - here is a question - you mentioned content of the pages playing a role in page load time, which is sensible... what is the role of caching in this circumstance, assuming that most of a page is cached data (either db query cache or APC etc)... does that become nearly a non-issue, or is it still significant in your experience?
I don't have experience with Linux, but have started experimenting to see what the learning curve will be. It seems manageable. Maintainability is a concern though.
ok - here is a question - you mentioned content of the pages playing a role in page load time, which is sensible... what is the role of caching in this circumstance, assuming that most of a page is cached data (either db query cache or APC etc)... does that become nearly a non-issue, or is it still significant in your experience?
I haven't done an extensive study of the factors here, but I can say anecdotally that courses with many many screen fulls of resources and activities will load more slowly than simple courses. In general, I think the progression in page load times become pretty linear as the content on the pages grows. I don't think the caching changes the relative load times all that much ie the relative time to load a short course page vs a long course page. In particular a short course page on an non-tuned server may load much more slowly than a long course page on a well tuned server.
I would not use the page load time as a criteria for course limiting course length. There are other factors such as instructional design that limit good course design more quickly than the likely impact on page load times on a well tuned server.
The other factor that limits caching of course is the amount of RAM. The more complex and larger your datasets the more RAM will be consumed to cache those. You will find a lot of posts on these forums discussing the importance of having adequate RAM in your system. This is especially true as you start to tune your server.
Basically the caching will have a dramatic impact on performance, but there is still no free lunch. Some resources will be used on the server with each page load. The tuning can lower the page building times on the server and or increase the number of concurrent users you can support, but each view costs a little bit of load on the server. Its just a lot less when optimized then when not optimized.
I would not use the page load time as a criteria for course limiting course length. There are other factors such as instructional design that limit good course design more quickly than the likely impact on page load times on a well tuned server.
The other factor that limits caching of course is the amount of RAM. The more complex and larger your datasets the more RAM will be consumed to cache those. You will find a lot of posts on these forums discussing the importance of having adequate RAM in your system. This is especially true as you start to tune your server.
Basically the caching will have a dramatic impact on performance, but there is still no free lunch. Some resources will be used on the server with each page load. The tuning can lower the page building times on the server and or increase the number of concurrent users you can support, but each view costs a little bit of load on the server. Its just a lot less when optimized then when not optimized.
Excellent points, Jonathan. At larger numbers of users, it's also essential to provide dedicated skillsets in DBA and SysAdmin - these need to be people with skill in building and maintaining an LMS system - which type of system by it's nature does a much higher degree of database writes than systems that most general purpose web site sysadmins are used to.
This is for an LMS system in general - institutiuons who host their own large scale Angel or Blackboard installation also generally have several staff dedicated just to DBA/SysAdmin roles - actively tuning the database and the server on an ongoing basis. As the usage of the LMS grows it becomes an enterprise system on the scale of importance and complexity of the ERP/SIS system the institution uses. Institutions typically dedicate several staff per 10,000 users to their backend ERP system - just to maintaining the backend. An enterprise LMS needs similar dedication of both hardware and staff resources to run well for 10s of thousands of users.
A big pain point many folks I consult with have is when they move from an experimental, lightly used system that is staffed by volunteers or 1/2 or quarter FTEs to an increasingly more heavily used system relied on by large numbers of the faculty, staff, and students 24/7/365.
ERP/SIS implmenetations went through a similar sudden growth from lightweight use to being heavily used for online registration, self-service of various institutional functions (add/drop, password change, bill paying, etc.) in the last decade - so these database intensive, critically important systems can provide some baseline information for staffing levels, hardware costs, etc.
Thankyou - that is helpful information