HackRU Load Tests

We used Locust to load test the HackRU server.

I created tasks that accessed every route on the server at about the same frequency,
with the homepage and account POST routes accessed twice as much as the default frequency,
by using the weight field of the task decorator on the methods of the User Behavior class,
which was defined as the task_set of the Website User class that extended HTTP Locust.

We reasoned with the kinds of loads and usage spikes we would have to handle.
-> Assume 800-1000 attendees. Assume 1/3 of registrants attend.
-> Assume 3000 registrants. Assume 1% of site visitors sign up.
-> Assume 300,000 requests.
...
-> Assume 1000 register in the first week, and 300 in the first day. (From last semester)
-> Maximum load will then be ~10,000 requests/day. Assume 90% of users register from noon to midnight.
-> 9,000 requests/12 hours = 750 requests/hour = 31.5 requests/min ~ 0.5 requests/sec
-> With these assumptions of high load, even spikes of 40x standard loads would be safe to handle.

http://imgur.com/nflRPlG
-> At 1000 users and ~20 requests/second, we see 50,000 requests send without a single failure.
-> The few requests that seem to have failed here are due to to client side errors where HTTP headers are empty.

http://imgur.com/h73hVEs
-> At 200 users and ~100 requests/second, we see 50,000 requests send with a ~10% failure rate.
-> These requests that have failed are due to "database locked" issues where two locusts try to register simultaneously.

-> At 2000 users and ~100 requests/second, the "database locked" issues cause a 50-60% request failure rate.
   But massive load spikes like this are not expected given our assumptions, and as this would be a spike,
   a browser sending these requests would have a stable connection and still render the website usable.
   While the above load test was happening, we used a browser and the average delay on buttons site-wide were 3-10 seconds.