Saturday, April 30, 2011

How to use jMeter in server mode over an SSH tunnel - Part 2 - Mutliple server instances

This article describes how to run one client JMeter instance with MULTIPLE server instances with inter-JMeter communication tunneled over SSH.

Please read the previous part first (How to use jMeter in server mode over an SSH tunnel).

1) SSH TUNNELS (created from the client machine)
We assume that:
- we have a client machine and a server machine
- client JMeter instance runs on the client machine
- both server JMeter instances run on the server machine.
- we have two server JMeter instances

Create following tunnels:
(tunnels to instance 1)
Local port: 55501 ->
Local port: 55511 ->
(tunnels to instance 2)
Local port: 55502 ->
Local port: 55513 ->
(mutual tunnel for callback)
Remote port: 55512 ->


Create 2 separate JMeter application folders on the server machine, e.g.
and put the patched JMeter application into each of them.

They will have different configurations in (The same result could be also achieved by having only one application instance and by specifying the different configuration parameters in the start up script on command line.)

Prepare start-up scripts:
./jakarta-jmeter-2.3.4-inst1/bin/jmeter-server -Djava.rmi.server.hostname= 2>&1 >inst1.log &

./jakarta-jmeter-2.3.4-inst2/bin/jmeter-server -Djava.rmi.server.hostname= 2>&1 >inst2.log &



5) GO
Open SSH connection from client to server machine
Start client JMeter
Start server JMeters
Remotely run your test
Check inst1.log and inst2.log for logs from the server instances

6) Done!

1) Ports are already in use on server machine
Make sure no previously started JMeter is running in the background.

2) There are no results coming back to client instance
Make sure you patched also the client instance JMeter application.


  1. Peter, this is perfect - works a dream! You're a legend.

    I might make one comment if I may which is to say that in Section 3 where you say:

    Create 2 separate JMeter application folders on the server machine, e.g.
    and put the patched JMeter application into each of them.

    This sounded to me like creating two instances of jmeter on one machine. If anyone else got a bit confused here what I did was to copy up the patched jakarta-jmeter-2.3.4 directory to two different servers (same dir name) and then edit their respective files as per the article.

  2. Hello,

    since I had only 1 client and 1 server machine I really ran two JMeter server instances on one machine. But there may be also real reasons to do it that way (utilizing hardware paralelism?, limits of single jvm, ..).

    You ran each server instance on a separate server machine? Are you saying that you opened separate SSH connections to both machines and that both connections were tunneling the same port 55512 without problem ? That's good news..

  3. PS. I changed your port 55512 to something else more distinct. Using 55511 for slave number 1 meant I wanted to use 55512 for slave number 2 but would have had to jump to 55513 instead.

    It's arbitrary really, of course any unreserved number works, but it made things more pleasing to the Freudian side of my personality.

  4. Yes, two server instances tunnelling to the same port. In fact, I ran it with three boxes as slaves, each using the same port - it works. Now, if I need, I can fire up as many cloud-based slaves as I desire - very useful, very cheap.

    And yes, I do this to give me access to additional hardware to generate the required load.

    There is one problem where connection warnings are intermittently written to the terminal that launched the tunnels but this does not seem to affect the test, it's just annoying for now, but I need to verify this.

    Overall, this solution is great for those scenarios where I am testing cloud based SUTs and need to generate load from an external source (the Cloud). This is desirable because I do not want traffic streaming out of my local network, which is unrealistic and problematic. So by using this tunnelling solution I can generate the correct load and benefit from rich, real-time feedback to a central location.

    The problem with remote, distributed testing (not tunnelling per se) is that you can end up saturating your incoming bandwidth, even with batch mode set. In this case there are really only two other options (which do not employ your solution):

    1. Run the test remotely in non-gui mode and use the 'generate summary report' listener to get feedback. Like this, there is no tunnel in use and you lose the GUI but you also remove the bandwidth issue and get a solid, reliable test. I think this is the traditional way of using JMeter in such a situation.

    2. Where I really want the extra feedback, I put my MASTER instance in the cloud too and push the GUI back to the client using X11 forwarding. I've only played around with this a bit so far; it works fine for simple tests but I've only tried it from home and it was painfully slow at times and did not seem to scale well. But I have naff broadband which was maxing out at certain points and I didn't really test it fully so I'll reserve judgement.

    Thanks again, great work.

  5. It is one of the foundations for the study of positive psychology, which seeks to focus on strengths and other positive attributes people possess that lead to living a good life, instead of pathologizing them. Thank you. forskolin