Difference between revisions of "WeBWorK performance"
(→Data) |
|||
Line 124: | Line 124: | ||
'''Note''': This server had two "out of memory" events which brought the server down due to a freebsd kernel setting that we should have tweaked but didn't until we understood the problem. This isn't a concern with the linux kernel or 64bit freebsd machines. These two events probably account for most of the requests on the high end. |
'''Note''': This server had two "out of memory" events which brought the server down due to a freebsd kernel setting that we should have tweaked but didn't until we understood the problem. This isn't a concern with the linux kernel or 64bit freebsd machines. These two events probably account for most of the requests on the high end. |
||
− | == |
+ | == Results from load monitoring software == |
=== Webmin on courses.maa.org === |
=== Webmin on courses.maa.org === |
||
Line 130: | Line 130: | ||
[[Image:Courses.webmin.load.week.png|frame|load on courses.webwork.maa.org 30 Aug 11 - 6 Sept 11 ]] |
[[Image:Courses.webmin.load.week.png|frame|load on courses.webwork.maa.org 30 Aug 11 - 6 Sept 11 ]] |
||
+ | == External Links == |
||
+ | * http://en.wikipedia.org/wiki/RRDtool |
||
[[Category:Administrators]] |
[[Category:Administrators]] |
Revision as of 11:07, 31 October 2011
Contents
The timing log
The timing_log_performance.pl
is available in webwork2/bin
and parses the timing log data found in webwork2/logs/timing.log
.
To run the script, cd
to the WeBWorK logs directory (usually /opt/webwork/webwork2/logs
)
and enter the command: timing_log_check.pl
Data
- From the
courses.webwork.maa.org
timing log:
Data from July 2010 - August 2011
count = 13427151
under 0.1 seconds = 7999616: 59.6%
between 0.1 and 0.2 seconds = 2864257: 21.3%
between 0.2 and 0.5 seconds = 1955285: 14.6%
between 0.5 and 1.0 seconds = 297585: 2.2%
between 1.0 and 2.0 seconds = 135471: 1%
between 2.0 and 3.0 seconds = 45002: 0.3%
between 3.0 and 4.0 seconds = 23265: 0.2%
between 4.0 and 5.0 seconds = 13663: 0.1%
between 5.0 and 10.0 seconds = 30677: 0.2%
over 10.0 seconds = 62330: 0.5%
non valid response = 0: 0%
- From the
courses.webwork.maa.org
timing log:
Data from September 8, 2011 - October4, 2011
count = 1982653
under 0.1 seconds = 1154514: 58.2%
between 0.1 and 0.2 seconds = 421666: 21.3%
between 0.2 and 0.5 seconds = 338780: 17.1%
between 0.5 and 1.0 seconds = 47763: 2.4%
between 1.0 and 2.0 seconds = 13555: 0.7%
between 2.0 and 3.0 seconds = 3367: 0.2%
between 3.0 and 4.0 seconds = 1267: 0.1%
between 4.0 and 5.0 seconds = 593: 0%
between 5.0 and 10.0 seconds = 780: 0%
over 10.0 seconds = 368: 0%
non valid response = 0: 0%
Note: The daily backup routine was moved from 12 midnight (a busy time for students to do work) to 6:00am. This seems to have resulted if fewer operations taking a long time.
- From the Rochester server
math.webwork.rochester.edu
timing log:
Data from September 6, 2011 count = 2586
under 0.1 seconds = 1795: 69.4%
between 0.1 and 0.2 seconds = 223: 8.6%
between 0.2 and 0.5 seconds = 515: 19.9%
between 0.5 and 1.0 seconds = 36: 1.4%
between 1.0 and 2.0 seconds = 8: 0.3%
between 2.0 and 3.0 seconds = 8: 0.3%
between 3.0 and 4.0 seconds = 1: 0%
between 4.0 and 5.0 seconds = 0: 0%
between 5.0 and 10.0 seconds = 0: 0%
over 10.0 seconds = 0: 0%
non valid response = 0: 0%
- From the Missouri server 32 bit freebsd 7.2 vm with 4GB of ram serving about 1400 students per semester from May 5 2010 to Oct 10 2011:
count = 4664624 under 0.1 seconds = 3696211: 79.2%
between 0.1 and 0.2 seconds = 536336: 11.5%
between 0.2 and 0.5 seconds = 363331: 7.8%
between 0.5 and 1.0 seconds = 48816: 1%
between 1.0 and 2.0 seconds = 13498: 0.3%
between 2.0 and 3.0 seconds = 2865: 0.1%
between 3.0 and 4.0 seconds = 1406: 0%
between 4.0 and 5.0 seconds = 666: 0%
between 5.0 and 10.0 seconds = 1036: 0%
over 10.0 seconds = 459: 0%
non valid response = 0: 0%
Note: This server had two "out of memory" events which brought the server down due to a freebsd kernel setting that we should have tweaked but didn't until we understood the problem. This isn't a concern with the linux kernel or 64bit freebsd machines. These two events probably account for most of the requests on the high end.