Stress Testing LifeType
From LifeType Wiki
This page is mostly oriented towards developers who want to test the effect of new features on the performance of LifeType, but it may also be used by users who wish to know how well (or badly) LifeType performs in their servers.
Contents |
[edit] Apachebench
http://httpd.apache.org/docs/1.3/programs/ab.html
ab is a tool for benchmarking the performance of your Apache HyperText Transfer Protocol (HTTP) server. It does this by giving you an indication of how many requests per second your Apache installation can serve.
[edit] Siege
http://www.joedog.org/JoeDog/Siege
Siege is an http regression testing and benchmarking utility. It was designed to let web developers measure the performance of their code under duress, to see how it will stand up to load on the internet. Siege supports basic authentication, cookies, HTTP and HTTPS protocols. It allows the user hit a web server with a configurable number of concurrent simulated users.
Siege is suitable when simulating 'Slashdot'-like effects where it is important to be able to repeatedly fetch the same URL as fast as possible. However, keep in mind that Siege only fetches the page itself, and not any of the related resources such as CSS files, icons or Javascript.
[edit] LifeType's own stress-testing tools
The LifeType project developed two additional scripts in order to be able to perform stress tests. Both these scripts are located in the tools/ folder.
- genloadtestdata.php
- play.py
[edit] genloadtestdata.php
generateData.php is able to crawl a LifeType database in order to generate pseudo-random URLs based on the contents of the database. This script does not perform the actions required to do the load testing, but instead generates the links that will be used by play.py.
The script currently supports generating GET requests to load blog links and permalinks, and POST requests to post comments.
There are few configurable parameters via PHP constants that are configurable, at the top of the file:
- NUM_REQUESTS: The number of random requests to generate.
- BASE_URL: The base URL that will be used for generating the random requests.
- GET_RATE: Percentage (1-100) of GET requests.
- POST_RATE: Percentage (1-100) of POST requests.
GET requests can be of two types:
- Blog links, such as http://.../index.php?op=Default&blogId=X
- Permalink, such as http://.../index.php?op=ViewArticle&blogId=X&articleId=Y
POST requests can only be of one type, to posts comments to a blog. The contents of the comment and topic are also totally random.
This script outputs CSV (Comma Separated Values) data, to the standard output. In order to capture this data, please run the script from the command line and redirect its standard otuput to a file:
php genloadtestdata.php > load_test_data.csv
Once we have a file with CSV data, play.py will take care of playing such kind of script.
[edit] play.py
play.py is the script that performs the requests to the web server based on a CSV file with data generated by genloadtestdata.php.
The script is build in Python and not in PHP because support for threading was required, and that is unfortunately not available in PHP.
The script supports several parameters that control its behaviour:
- -f file: specifies the CSV file with data to load.
- -w milliseconds: number of milliseconds to wait between each one of the HTTP requests performed by the thread.
- -n number: defines the number of threads that will process the CSV script. All threads will be processing the same file in the same order.
- -o file: specifies the CSV file where test data will be written to. Please do not specify the .csv extension, as it will be appended automatically. Whenever requesting script data to be saved, the script will generate at least one file with the average data for all threads and requests, as well as one CSV file per thread (named file_X.csv) where X is the thread identifier.
- -t seconds: defines the number of seconds for which the script will run. This allows to execute the same CSV script over and over again for for example ten minutes or one hour.
For example in order to execute one single CSV script with only one thread and making requests as fast as possible (no wait time) for 15 minutes (900 seconds):
play.py -f test_script.csv -t 900
Run the script only once, with 10 threads with a wait time of 4 seconds (4000 milliseconds) each and output the results to another CSV file:
play.py -f test_script.csv -n 10 -w 4000 -o results_test_script
play.py will display some statistics upon completion such as the average number of requests per second, total time required to execute the test, etc.
