I'm using the Apache 'ab' (Apache Benchmark) tool to profile our Moodle 1.9.x deployment. In order to profile the site properly I would like to look at how pages such as course/view.php, mod/resource/view.php etc. perform under load. Obviously, these pages are behind an authentication boundary and therefore can't be accessed directly. Has anyone successfully used profiling tools like 'ab' or 'siege' to profile pages that are inside Moodles authentication boundary?
If you're using apache bench, just grab something like the "Live HTTP Headers" plugin for Firefox (or something else that allows you to see the headers that are actually being sent back and forth). Log into Moodle via the browser, making sure to open the Live HTTP Header tool first. You'll see something like:
The second half will, of course, be different with every login, so if you get logged out, you'll have to go through this step again.
Then just pass it into ab like so:
ab -C MoodleSession=2bc6ap2ruk0kemrcsc1eelsjl6 -n 100 -c 10 http://your.moodle.site/
adjusting parameters to taste. The first one's the important one. I'm sure there's something similar for siege but don't know offhand.
To get a more acurate measure of real Moodle/Apache thoughput we have used the WebLoad tools. (see http://www.webload.org/) The tools tell us exactly how man concurrent session are being run. We can then throtle more concurent sessions until we make the server go belly up. A lot of thought must go into the session scripts to make the data valid and a reflection of real world use. There are also some Moodle settings that must be re-configured. To be able to test down to the quiz level, automatic randomizations of questions and quizes must be turned off. Each session script has to be added to provide a unique logon id, and all the logon ids must be pre-enrolled in the course under test. The course may need to be reset between each load test. The session scripts are simply a keystroke record of a session where you simulate the use you are trying to test. The session sciprts then can be edited for a large number of users and various delays can be inserted or removed to better simulate the mix of users. The start up and loading of the sessions can be timed or programmed to simulate everybody jumping on the machine at once or for a closer to normal system usage.
Thanks to the data from our testing we were able to tweek the OS and Apache configs to host about 1900 sessions before we brought our server to it's knees, so to speak. [server info: Dell PowerEdge 2950 32GB memory, 4 64bit cpus, direct attached scsi disk 400GB separate LDAP server, separate mysql server] We did some runs only for log-in testing strictly to test the authentication server.
Which ever way you choose to do load testing be prepared for some long hours.
Thanks for the replies Tim & David.
I've managed to get Apache Benchmark working per Davids suggestion.
Its really handy for measuring server throughput under defined loads. What I'm struggling to figure out now is how to measure the actual throughput of my web server i.e. on an average day, how many requests per second is it actually serving. Is there a way to determine this?