My workplace is connected via cable internet with limited up/downstream, so for load-testing a web application I am using a distributed approach:
- An instance of jmeter-server (v2.4) is running on a remote linux box which has proper internet connectivity.
- The controlling jmeter GUI (also 2.4) is running on my desktop.
- The two are connected via a VPN.
- The SUT is a web-application hosted in another datacenter.
This works fine – I am able to start the remote thread execution from the jmeter GUI and receive live results in the Summary Report.
The weird part is that my ability to put real load on the SUT is limited by my local internet connection (inbound, downstream). Tracing the link between the local jmeter GUI and the remote jmeter-server, I can see that all HTTP-traffic from SUT towards jmeter-server is sent to the local jmeter GUI. So if the jmeter-server is retrieving a 1MB file from the SUT, it’s then sending it to my local jmeter GUI (over my slow internet link).
Is that how it should be? I was expecting that only the key measurements would be transported (success, latency, etc).
[PS: I know I can scp my testplan across to the remote box and run it in a headless jmeter. But then I don’t see live results…]
This is probably because you are having a “View Tree Results” in your jmeter script. This tells the server to send all responses back to the master so you can view them. That will quickly fill your bandwith and is memory intensive. Try to disable all listeners in your script and only have the “View Aggregate results” one in there.
With high load, you’re not interested in individual results. There is also no need to open up your firewall in your datacenter if you use ssl tunneling. I’ve documented that in a blogpost because I couldn’t find a simple step-by-step online, you might want to check that out too at http://rolfje.com/2012/02/16/distributed-jmeter-through-vpn-and-ssl/