[Building Sakai] Sakai scalability monitoring and testing
Ray Davis
ray at media.berkeley.edu
Mon Mar 9 10:46:48 PDT 2009
Lately at UC Berkeley we've been trying to better understand (and
hopefully reduce) our ongoing performance and scalability woes. Some
sakai-dev readers might be interested in the code we've recently checked
into the Subversion repository, since it's already uncovered a couple of
bugs and cleared up some lingering questions. None of the logic is
particularly Berkeley-specific, and if anyone's interested in adapting
it or further generalizing it, the task shouldn't be very difficult. But
we're not at this moment volunteering to support the world. :)
All of scalability is divided into three parts:
A. Collecting statistics (from production and QA environments for
diagnosis; from test environments for continuous integration testing).
B. Mimicking production activity (so that we can repeat tests and we
aren't completely dependent on production systems for data).
C. Mimicking production data (so that we can begin tests from a known
starting point).
For statistics, we're currently using a mix of standard Tomcat garbage
collection logs (analyzable by gcviewer), JMX MBean statistics
(periodically written out to the Tomcat log), and the JAMon open source
monitoring library. JAMon's a bit stodgy, but the other options I tried
weren't free, weren't flexible enough, or couldn't deal with Sakai's
bizarre classloader environment. The bulk of the JMX and JAMon work is
checked in at:
https://source.sakaiproject.org/svn/msub/berkeley.edu/bspace/jamon/sakai_2-5-x
For mimicking activity (AKA stress testing or load testing), we're
currently using an easily configurable layer on JWebUnit / HtmlUnit. It
doesn't do anything terribly sophisticated, but we don't need to do
anything terribly sophisticated to bring our servers to their knees.
For mimicking production data (AKA data loading), we're using a Groovy
script, and I'm mostly running it from the command line via the
test-harness's component manager emulator.
(And here let me just inject an unsolicited enthusiastic plug for Thomas
Amsler's fine, fine Sakai Groovy Shell:
<http://confluence.sakaiproject.org/confluence/display/SGS>. Code a
couple lines; run 'em; see what happened; edit 'em; repeat.... It's
scarily like rapid development!)
Since cleanly repeatable stress tests need to be matched to known test
data, both of these aspects are currently checked into the same
top-level project:
https://source.sakaiproject.org/svn/msub/berkeley.edu/bspace/stress-test/sakai_2-5-x
The stress testers are at:
https://source.sakaiproject.org/svn/msub/berkeley.edu/stress-test/sakai_2-5-x/stresser
The data loader is at:
https://source.sakaiproject.org/svn/msub/berkeley.edu/stress-test/sakai_2-5-x/dataloader
Best,
Ray
More information about the sakai-dev
mailing list