Load Testing nanoTwitter

Load Testing

  • Testing a product to see how it performs under load

Deployment

  • Obviously to do load testing, your app needs to be running on a server, separately from your own computer.
  • This could be any server, even your neighbor’s laptop.
  • For our purposes, it needs to be on one of the cloud services, like Heroku
  • I recommend Heroku
    • if you are adventurous you could deploy it elsewhere too.
    • But then we won’t really be able to give you too much help
  • Cloud deployment implies that there is a well known ‘fixed’ domain name
    • (e.g. wild-mushroom-2312.herokuapp.com)

App functionality

  • Each team has deployed nanoTwitter and has supplied us with the domain name
  • Each implementation of nanoTwitter follows the same spec
  • In particular, implement the url routes exactly as specified.
  • This allows a unified test to be run against all of the apps

Load Testing Tools

How to deal with authentication

  • Initial tests should be constructed so that they don’t require a login
    • For nanoTwitter, displaying of the non-logged in home page
  • Later tests will require a log in
    • Note that within loader.io there is a provision for authenticating using basic authentication.

Standard Seed Data

  • To allow us to compare apples to apples we have Seed Data
  • Adapt your code to use this Seed Data

Standard configuration parameters

  • Non-logged in page displays the 100 most recent tweets

Reporting

  • Keep a careful lab notebook!
  • Make note of configuration changes that you try
  • Collect data and try to interpret it

When your app is failing to scale

  • Think about what happens when your app response time is longer than the time between new connections. Requests will start to pile up.
  • If it takes too long for a request to reach the front of the line, it will time out.
  • If your app is too overloaded, it may shut down entirely. Make sure to consult your Heroku logs after a test to identify this.
  • When an app hasn’t been accessed for a while, Heroku will put it in a sleep state. If your app is asleep, make sure to access it manually to wake it up before beginning a test. Waking up may take several seconds, which would influence your results.

Using Loader.io

  • Our goal is to see how well each of your servers survive the onslaught of traffic
  • Take a look at Loader.io
  • Use the “maintain client load” option (at least to start.)

Test 1: Simple display of home page

  • Visit your root page (which will display a set number of tweets)
  • Use Loader.io to hit that page using maintain client load
  • Collect and record data

Test 2: Display of a certain user’s home page

  • Visit /user/1 to display User 1’s home page
  • Visit /user/100 to display another home page
  • Collect and record data

Test 3: Do some analysis

  • Form some hypotheses about what is going on with your performance
  • Make a report correlating load to performance
  • Try heroku pg:outliers to see if it tells you anything about your db performance