a nice tool to go frenzy on a webserver is siege. it simulates an editable amount of concurrent users that pick on the web server for a variable time. having found this tool, stress testing some TYPO3 instances on apache(s) i rule was the inevidable next step.
now first of all this is not my daily business, but it’s tending to become to, so if you have corrections, suggestions and comments, your lines are appreciated below. the post you read is more like a small tutorial for those who want to know how performant the own webserver (i.e. apache) does. i like siege because of the easy settings, but i also run the better known apache benchmark when it comes down to a single page.
preparing the battle
get all urls from the system, it’s willing to accept and put them in a text file line by line. my TYPO3 (4.3.0a3) runs realurl, so the trick is easy.
- make sure, all the pages have been visited (# wget -r does the job)
- ask mysql or phpmyadmin to provide following data
SELECT spurl FROM `tx_realurl_urldecodecache` WHERE 1=1 LIMIT 0 , 4500
sure, one could narrow the links down by using WHERE rootpage_id = [domain1_id] but as the whole server is to be tested, give me what i can get.
- grab the result into a file and prefix every line with the base url defined in config.baseUrl.
the lines should like like clickable http requests. exactly that is siege going to do.
“http://baseurl.com/spurls/from/decodecache/” <- the way i did it
- if you’re into MySQL profiling, a tool like jet profiler can make your day. innoDB ftw!
- clear all caches in TYPO3 (and read stuff written in nc_staticfile manual:)
Clear cache for all domains in tree
Here you can decide what to do when clearing the frontend cache. By default all static html files will be deleted. Usually this is fine. Most installations of TYPO3 serve a single domain. If multiple domains are served from the same TYPO3 tree you might want to leave the cache for the other domains intact. If you uncheck the ‘clearCacheForAllDomains’ checkbox, only the html files are removed that are in the same domain as which you are logged into the backend.
- after the siege battle you will start thinking about using a static file cache… if you haven’t already
- machine A is going to battle machine B, so B would serve http://baseurl.com/ and A has siege installed and a file with the lines built above, named realurls.txt.
- now you run a command like
me@machine1 [/home/me] siege -c 60 -t 5M -i -b -f realurls.txt > /dev/null
-c 60 # makes siege simulate 60 concurrent web users, i think that’s a number
-t 5M # the battle will last around 600 seconds
-b # benchmarking mode, leave no delay between requests -> make the box steam!
-i -f realurls.txt # internet activity mode, the links in realurls.txt are randomly clicked, rather than sequentially
> /dev/null # the output is going to the built-in black hole, better than flaming my console. you may prefer logging to a file.csv which contains info on the single requests (useful for finding the slow pages)
- hit and see
** SIEGE 2.69
** Preparing 60 concurrent users for battle.
The server is now under siege…
i was prepared for stuff but that hit me down (hopefully your first values are better)… after a while results are shown.
benchmark results
| Response time: |
4.15 secs |
| Transaction rate: |
12.06 trans/sec |
| Throughput: |
0.28 MB/sec |
wtf! the machine got spikes in the load like 25! this is not what i expected. i was aiming for about a mean response time of shorter than a second and, #whatdoiknow, about a hundred successfull transactions per second?
now it’s definitely time to optimize some settings. right now (two days later), the same box drives like
| Response time: |
0.13 secs |
| Transaction rate: |
507.40 trans/sec |
| Throughput: |
2.78 MB/sec |
load below 4. not bad, hu? most tweaks (apache, mysql, TYPO3) i did to achieve this will be written in one of the next posts, as i’m not finished yet ^ #botmustwork
(you see result of iteration 1 and i think 8. the siege settings haven’t changed, of course cache revalidation was disabled)
conclusion
if you’ve got a web site up and running, you’d better be looking on performance in the real world. is the page digg-proof and does it stand a large amount of requests over time, even when cache was cleared? siege can help in doing a forecast.
after the site gone public, you will try to avoid becoming host of dead ends.
