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?
Display of the logged in page
Performing a single tweet
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
We are all using 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
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