/
/user/1234
/search
/search?phrase=
/register
/login
/logout
The Test Interface essentially is a set of URLs which invoke special functionality that allows your nanoTwitter to be tested from a browser, and is the foundation of the scalability testing we will be doing.
It works by implementing some special routes (that all start /test/xxxx) that do operations which a normal user would never do. Because of this, when this was really deployed, you would protect those routes through the firewall to make sure that no-one but the developers could access them.
These routes will be used during the load testing to reset the server, create lots of fake users, measure performance and so on. It’s analogous to the Onboard Diagnostics Interface that all cars have. There’s a plug near the steering wheel that you probably never noticed, where the mechanic (or you) can plug an instrument to inspect the internal condition of the car.
There’s a user that we use as part of many of the tests. We refer to the user as “testuser”. When you create that user use the following attributes:
?user_id=x
GET /?user_id=x
GET /test/reset?user_count=u
/test/reset?user_count=10
GET /test/tweet?user_id=x&tweet_count=y
GET ../test?user_id=123&tweet_count=22
GET /test/status
/test/status
GET /test/validate?n=n&star=u1&fan=u2
fan
star
n
GET /test/corrupted?user_count=u
GET /test/stress?n=n&star=u1&fan=u2
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!
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:
/?user_id=n
/search?phrase=z