Hello!
It's the first day of term, and everything's gone belly-up.
Our login page is served and handled via HTTPS, and it's been as responsive as I would expect all summer (when no-one was here). However, now everyone's back, it's slowed to a crawl, taking up to 15 minutes to load the page.
Our Moodle install is running on a LAMP stack under Ubuntu Hardy. Our network monitoring software has flagged a timeout when trying to send HTTPS requests to the server. HTTP is slower than it was, but still acceptable.
I've had a look at the Apache error logs which seem to show nothing untoward, and am now at a loss. Can anyone suggest what might be going wrong?
I'm running 1.9.5+, with all the latest updates from CVS as of this morning.
Thanks
(why?) are you using https for moodle logins? have you used it ok previously?
from my experience, https does degrade performance bcs data served has to be encrypted/decrypted between the end-user and web server and vice versa.
there are plenty of other ways to secure your moodle, but i appreciate you're trying to protect usernames:passwords
from my experience, https does degrade performance bcs data served has to be encrypted/decrypted between the end-user and web server and vice versa.
there are plenty of other ways to secure your moodle, but i appreciate you're trying to protect usernames:passwords
We use HTTPS to protect usernames/passwords and student details. It's been fine up until now, it worked fine before (and during) the summer. (It's also working at the moment, although sporadically).
I'm worried I've changed some server configuration during the summer but I can't think what, and I don't really know what to look for - I've had limited past experience with HTTPS.
I'm worried I've changed some server configuration during the summer but I can't think what, and I don't really know what to look for - I've had limited past experience with HTTPS.
Is it anything to do with Moodle at all? What is your underlying login system - if you are using (say) LDAP then the problem is much more likely to lie with the response of that system.
Are you saying that you have tried it with HTTP and it works fine?
Have you tried one of those speed tester things (e.g. YSlow for Firebug) to see if you can spot which bit is causing the delay?
Are you saying that you have tried it with HTTP and it works fine?
Have you tried one of those speed tester things (e.g. YSlow for Firebug) to see if you can spot which bit is causing the delay?
We're beginning to think it's a network issue rather than a Moodle issue. Our network monitoring software (Opsview) is showing the HTTPS and HTTP ports on the Moodle server (but no other servers, even other VMs on the same physical server) as "Critical", meaning that they don't respond within 10 seconds. HTTPS is in this state more-or-less constantly (started at 8.20 this morning) but HTTP is slightly better.
Moodle is still accessible while the services are critical, but it's taking up to half an hour to load the login page.
YSlow doesn't show anything hugely suspicious on the page. The number of HTTP requests scored "D".
Moodle is still accessible while the services are critical, but it's taking up to half an hour to load the login page.
YSlow doesn't show anything hugely suspicious on the page. The number of HTTP requests scored "D".
Our old IT manager says it sounds to him like it's an issue with Moodle code as the rest of the server is fine except those two ports.
As I say, it worked fine last year so that means it must be something I did over the summer. The only thing I can think of that would effect the login page is the new theme I implemented (it uses a javascript menu, so includes some libraries which would generate extra HTTPS requests). However, changing this theme to one of the defaults doesn't seem to help.
Does anyone know a method of tracking down the issue, if it's being caused by the PHP code?
As I say, it worked fine last year so that means it must be something I did over the summer. The only thing I can think of that would effect the login page is the new theme I implemented (it uses a javascript menu, so includes some libraries which would generate extra HTTPS requests). However, changing this theme to one of the defaults doesn't seem to help.
Does anyone know a method of tracking down the issue, if it's being caused by the PHP code?
I am having the exact same problem on a Macintosh. Has anyone found a cause and a solution?
Mark
It turned out the problem was with Apache.
We've had an increased demand on Moodle this year (as people are being pushed to use it more) and Apache wasn't configured with a high enough MaxClients setting. Additionally, the KeepAliveTimeout was set too high, so when someone did connect, it held on to them for a long time and no-one else could connect.
Part of the cause for this was the instruction we followed on the wiki's Performance page regarding the KeepAliveTimeout requirement of at least 60 seconds if using SSL in combination with IE (the page mentions that having the setting below this may cause the entire Windows TCP/IP stack to crash).
For the record, We're using IE 8 and Windows XP, with the regular KeepAliveTimeout now set to 5 and the SSL KeepAliveTimeout now set to 15, and have not experienced this bug (we use SSL only for logins, and profile pages). Does anyone have more specific information about it, so that we can ensure the wiki is as accurate as possible?
We've had an increased demand on Moodle this year (as people are being pushed to use it more) and Apache wasn't configured with a high enough MaxClients setting. Additionally, the KeepAliveTimeout was set too high, so when someone did connect, it held on to them for a long time and no-one else could connect.
Part of the cause for this was the instruction we followed on the wiki's Performance page regarding the KeepAliveTimeout requirement of at least 60 seconds if using SSL in combination with IE (the page mentions that having the setting below this may cause the entire Windows TCP/IP stack to crash).
For the record, We're using IE 8 and Windows XP, with the regular KeepAliveTimeout now set to 5 and the SSL KeepAliveTimeout now set to 15, and have not experienced this bug (we use SSL only for logins, and profile pages). Does anyone have more specific information about it, so that we can ensure the wiki is as accurate as possible?
Mark,
We had some problems a while ago with MaxClients too. I got some very helpful advice which I have linked to here: http://docs.moodle.org/en/Talk:Performance
Jon
We had some problems a while ago with MaxClients too. I got some very helpful advice which I have linked to here: http://docs.moodle.org/en/Talk:Performance
Jon