This is an example load testing application that may be run against the Meteor Parties example. It actually simulates clients and their behavior rather than just the messages exchanged between client and server.
Remember: DO NOT RUN THIS AGAINST ANY SERVERS THAT ARE NOT YOURS! ESPECIALLY NOT AGAINST METEOR.COM!
This example expects one running Meteor server. Also there should be at least one drone (machine to run the client simulation).
Create the meteor parties example and run it on the server you would like to test:
$ meteor create --example parties
Hint: This test will not differentiate between MongoDB and Meteor.
The machines used for testing (client drones) must be accessible via key and not ask for a password when you try to connect via ssh. Furthermore you must install both [PhantomJS]:http://phantomjs.org/download.html and [CasperJS]:http://docs.casperjs.org/en/latest/installation.html on the drones.
- Clone this repository
- Set up SSH keys to connect to your drones
- Add the IP/address of your drones to the
dronesfile - Add the e-mail addresses to be used for the test in the
accounts file - Run the parties example and make sure the drones can access the URL
- Start the drones using
$./start.sh -u http://mytesturl:3000 -d /home/meteor -p password - Open your URL and watch the Party Frenzy begin!
- Use
stop.shwhen the parents are home again.
This is in the package:
This is the actual user simulation. It tries to register an account with the app. If that fails, it tries to log in instead. If that fails as well, it gives up. Once authenticated it creates a party somewhere and then RSVPs for a random other party.
You can call this script directly using
$ casperjs parties-stress.js --url=http://mytesturl:3000 [email protected] --password=password
If you do not provide any arguments, default values will be used (most importantly it will run against http://127.0.0.1).
Inside the drones file enter the URL or IP for each of your client machines used during testing. Make sure to hit return after each entry!
List all the email addresses you wish to use as accounts for your drones. They will use them randomly. Watch out - there is no guarantee that one account is only logged in once at a time! Also you need to add a newline after the last entry.
In case you want to keep the password private it is not stored inside the accounts file. You will have to provide it on the command line instead.
These help you scale the testing. start.sh copies all files to the drones, immortalCasper.sh calls the parties-stress.js infinitely, and stop.sh will kill it from all drones.
start.sh is used like that:
$ ./start.sh -u http://mytesturl:3000 -p password -d /home/meteor
Once executed the testing begins and your URL will get hammered with never-ending requests.
It doesn't take any arguments, just call it to stop the immortalCasper instances.
This script initiates the casper process. Once finished, it will call it again. And again. And again. And...
./immortalCasper.sh -u http://mytesturl:3000 -p password
Because these scripts will only generate load or stress on your server, you should contemplate how to monitor your servers behavior. One suggestion is to add Kadira to your application. Alternatively, if you are running on your own infrastructure, you should use dedicated monitoring software such as Munin to observe your applications behavior.
- Sometimes a selector for a party throws an error - no idea why.
- Between runs users are not logged out.
- There is no easy way to retrieve the number of currently running clients, you need to keep track manually.
- Running multiple times on the same drone is quirky. Try using a different account for a second instance.
Created by Stephan Hochhaus, July 2014.