Testing Scalability (Thu Mar 10, lect 14) | previous | next | slides |

How to approach the analysis of scaling, in particular for nanoTwitter

Logistics

General Notes on Review of your code so far

  • There should be a test/ directory with tests written prefarably in Minitest although RSpec is ok too
  • We will try and run your test, so make sure your readme gives instructions if they are anything other than rake test
  • Remember the change history in your Readme with team members’ contribution, who worked on what.
  • We are continuing for a little bit longer on the previous two lectures.
  • Exercise: Write a test script for a class that is designed to take care of the parsing of a tweet, and extracting #hashtages, @mentions, and anything els

What does scaling mean for nanoTwitter?

  • What kinds of activities will likely demonstrate a scale problem?
  • Why would each of these possibly challenge scalability?
    1. Display of the logged in page
    2. Performing a single tweet
    3. Using the API

Discussion: where in the code will we find problems?

  • When displaying a single page requires many database accesses?
  • When loading a page requires server to send many megabytes of html?
  • When displaying a single page for some reason takes a lot of time?
  • What are your goals for nanoTwitter?
Discuss Each team have a discussion and report out where you think you have to be careful about scaling and what techniques or ideas you have which may help (or harm) scale.

Load Testing

  • Testing a product to see how it performs under load
  • 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 Digital Ocean or Heroku
    1. We are all using Heroku
    2. if you are adventurous you could deploy it elsewhere too.
    3. 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 (NanoTwitter Functionality) including the nT Test Interface
  • In particular, implement the url routes exactly as specified.
  • This allows a unified test to be run against all of the apps
  • To allow us to compare apples to apples we have Seed Data
  • Adapt your code to use this Seed Data

Load Testing Tools

How to deal with authentication

  • The nT Test Interface / specifies an authentication bypass argument
  • All your urls will need to check for the special argument in the url: ?user_id=x
  • If you see that argument, then you bypass the normal login sequence and instead set x as your currently logged in user by storing it in your session variable.

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

Thank you. Questions?  (random Image from picsum.photos)