Generating load using real browsers
Problem: Unrealistic Load Tests Problem
Previously at BU, we’ve used tools like Siege and NeoLoad to generate load on our test servers for our load testing. We’ve realized that this often doesn’t create a realistic view of what happens when actual traffic hits our websites. The problem with these load test tools is that they do not make the dynamic javascript/css/etc requests that normal users or browsers also make. And they don’t maintain a connection with the server long enough to get those assets, i.e. do not wait until the onload event is fired.
Solution: Load URLs using Real Browsers
I’ve created a load-urls.py script in the bu-toolkit repo which loads up urls from a file in multiple browsers at the same time. The script will wait until the onload event is fired on the page to consider it ready. It uses Selenium’s webdriver library to facilitate this work and supports browsers such as PhantomJS (default), Firefox, and Chrome. The benefit of using PhantomJS is that it is by default a headless browsers, whereas the other browsers require special headless versions and/or virtual displays to get working optimally.
Analysis
Running some adhoc urls for our TEST servers, I was able to make the following observations:
| Threads | Load Average on each TEST server |
| 5 | ~1 |
| 10 | ~1.75 |
| 20 | ~3.25 |
It should be noted that I was not able to run the 20 threads on malahide server (the server used to run load-urls.py) for too long as it’s own load average climbed up to 15. Also running the script for too long at just 10 threads may cause the server to become unresponsive, as it did to malahide server. So we need to use multiple servers set at 10 each to generate greater load for a short period of time. However, if the load needs to be maintained for a longer period of time, the task should be subdivided even further.