Last Thursday we launched a complete rewrite of a medical education testing system at work. It was probably the most significant project launch of my 18 year career as a computer programmer when you recognize that one of the top medical schools in the country will be using it to test their future doctors. Over the next few posts on this site (with the exception of any podcast episodes), I'll be detailing quite a few tools, decisions, etc. that were utilized and debated during the last month or so of development, including a full postmortem that I will probably cross-post to LinkedIn (and maybe Medium--still not sold on that platform).

For now, with the project finally winding down--along with the stress level--I'm getting back to spending more time with my twins, more time reading, and finally getting back to the keyboard with this post. We're going to start small though, and take a look at a nice little tool that helped with load testing before the launch.

Building an online testing system is different than building an online testing system that scales and performs for a large audience. This year, for in-class quizzes, 156 students will be occasionally hitting the application at a single time: 156 students taking a 10 question quiz over the course of 10-15 minutes for a total of 1,560 logged responses. This doesn't even include the fact that the students can strike-through answers, add comments, add highlights, and mark the question for addressing later. Factor in calls to the database to fetch the questions, answers, and assets, as well as remembering the students' configured items, and you have the potential for a lot of database calls--the primary bottleneck of any application. Oh, and this application is up for first year medical students. Next years, when second year medical students are included, you could potentially have 300-400 users hitting the testing system concurrently. To put things into perspective, Moodle--a popular open-source learning management system with quiz functionality--is known to have significant performance issues at 200 concurrent users.

There are always things to do that can increase performance, but going in blindly only helps low volume applications. The Apache foundation has an excellent command-line tool called Apache Bench. For most Linux machines, it's already installed. If you're on a Windows box, you can install Apache and access Apache Bench from the bin directory--it's available with a XAMPP installation.

How simple is it? Just drop into a command-line and type:

ab -n 10 -c 100 http://localhost/application/page
    

In this, n is the number of requests to make, while c is the number of current users to test against. For the URL, point to the path that you want to test.

This works in a pinch if you have an idea of which page in your application has the greatest performance issues. Apache Bench also allows for BASIC authentication if needed, and several other features, such as mimicking cookies.

We used Apache Bench as a secondary test to verify the results of JMeter, and it worked well in my opinion.