In spite of various past attempts at optimizing our server, we still seem to run into times where the server temporarily grinds to a stand-still. This does not necessarily coincide with high traffic times. We have a very light summer term happening right now, with only a few sections using WeBWorK during this time, but we have still had several occasions where the server significantly slowed down.
I'm wanting to try to identify exactly what is causing the slow-down so that we can have a better chance at fixing/preventing the issue. We have wondered about the impact of instructors using Library Browser, but have not definitively made any findings.
I don't know many of the technical details about our server. IT runs a virtual server (VMware) that hosts WW as a virtual machine. They indicate that the server itself does not seem to be overworked. I have login permission to the server and see that it is running Ubuntu 10.04.4 LTS, there appears to be 7.57 GB RAM.
We've already set Apache's options for MaxClients at 30 and MaxRequestsPerChild at 100 based on some earlier feedback, and that seems to address some of the slowdown. But there are still occasions where everything just grinds to a halt.
I'm happy to go into more detailed discussions via IRC, but thought a thread on the forums might also be useful. I'll post more as I find it.
D. Brian Walton
James Madison University
Hi Brian,
Perhaps the reason for the slowdown could be the same as in this thread?
The slow-down described in the link has to do with teachers building problem sets rather than the number of connections. It is pretty easy to reproduce: Create a problem set in the library browser, and keep adding problems to it from different libraries for a while. You should experience a slow-down within 5-10 minutes. Re-ordering problems in a set also seems to produce the same slow-down.
Lars.
Lars,
I saw the first part of that thread (and even commented). But I missed the follow-up somehow where Alex described an actual circumstance and possible fix. We've implemented that change (watching the Apache2 thread sizes). Hopefully, the issue is now resolved, but I'm still hoping to do some testing of the server.
- Brian
I saw the first part of that thread (and even commented). But I missed the follow-up somehow where Alex described an actual circumstance and possible fix. We've implemented that change (watching the Apache2 thread sizes). Hopefully, the issue is now resolved, but I'm still hoping to do some testing of the server.
- Brian
Hi,
On the MAA server doing backups originally caused a slowdown. First make sure the backup routine does not backup WeBWorK's tmp files which you should place in a separate wwtmp directory ---
see http://webwork.maa.org/wiki/Store_WeBWorK%27s_temporary_files_in_a_separate_directory_or_partition
Also it is a good idea to use cron jobs to keep the temporary files manageable --- see http://webwork.maa.org/wiki/Clean_Out_Temporary_Files#Using_Cron_Jobs_to_remove_temporary_files
Finally run the backup routine at a time when the load on the server is light, e.g. 6:00 am.
To lesson the load on the server you should be using lighttpd --- see http://webwork.maa.org/wiki/Serving_static_files_with_lighttpd
Finally you can check the performance of your server compared to a few others --- see http://webwork.maa.org/wiki/WeBWorK_performance#The_timing_log
The MAA and Rochester servers are virtual machines.
The above suggestions may not solve your problems, but they are good things to do on any WeBWorK server.
Arnie