Scalability Runoff 1 (Tue Apr 26, lect 25) | previous | next | slides |

First Try

Logistics

  • Today we will go through the whole scalability runoff for the first time.
  • Tomorrow we will finish

Scalability Runoff

  • A standard set of torture tests that each team’s nT will be subjected to
  • This is just one of many metrics that we will assess your team’s work by

Level Playing Field

  • Any database, or services, or http server, are permitted
  • Complete seed data set (we will check!)
  • Any caching, queueing, etc are all ok
  • But it all has to be at the $0 tier (except for db if you need it)
  • No paying for extra powerful services!

Scalability Testing Protocol

Here’s how testing of scaling will be done with loader.io. You need to make sure that your version of nanoTwitter performs as well as possible in these scenarios!

Setup

Before we can run each standardized test, we want to get each server to a known state we do the following commands directly from a browser. We want to make sure that the complete seed data is loaded. We will ask you to show us this before the test. The numbers are approximately:

  • x users
  • y tweets
  • z relations

Required urls (all have to be GET)

  • /?user_id=n
  • /search?phrase=word
  • /test/user/tweet?user_id=x&tweet_count=y
  • /test/reset?count

Test Scripts

  1. Rotate through 5 different user-ids, including testuser
  2. Rotate through 10 different urls, as follows:
  3. 7 times /?user_id=n
  4. 2 times `/test/tweet?user_id=x&count=y
  5. 1 time /search?phrase=z

Test runs - using maintain client load

  1. Run payload with u=250
  2. Run payload with u=500
  3. Run payload with u=1000
  4. Run payload with u=2000

Data Collected

  • Ave response time
  • Worse response time
  • NUmber of timeouts
  • Number of successes