Setting-up JMeter in Master-Slave Mode

There is abundant material available on the net on setting up and using JMeter; but sometimes the sought bit of information gets lost amidst too much information. Hence, listing out the basic steps of setting up JMeter in master-slave mode.

• Have Java 1.6 or higher installed on your system
• Download Apache JMeter Download Link
• Just unzip the downloaded file and place it at two suitable locations, say C:/Software/Tools/JMeterRoot/Slave and C:/Software/Tools/JMeterRoot/Master (two locations because remember, we need two instances of JMeter one running in Master and the other in Slave mode)
•  Some other miscellaneous requirements can be found at the Apache Site 

Steps for setting up the Slave:

• Go to the 'bin' directory where JMeter is placed, say C:/Software/Tools/JMeterRoot/Slave/bin)
• Open the 'jmeter.properties' file (and update some properties)
• Choose a port number at which the Slave is to run locally, say 6000 and then set this as the port number by updating:  server.rmi.localport=6000
• Then pick another port number at which the Master would connect to the Slave, say 1664 and update the following two properties, server.rmi.port=1664 AND server_port=1664
• And update the 'rmi create' attribute to true, that is; server.rmi.create=true
• Next, pull up a console and go to this 'bin' directory and type 'jmeter-server.bat' (in case of a Windows System) or just 'jmeter-server' (in case of a *NIX System)

This  will bring up the JMeter console with an instance running as Slave.


Steps for setting up the Master:

• Go to the 'bin' directory where JMeter is placed, say C:/Software/Tools/JMeterRoot/Master/bin
• Open the 'jmeter.properties' file
• Modify the property 'remote_hosts' and add the <hostname>:<port number> of all the Slaves that were set-up above, that is, remote_hosts=202.202.202.202:1664
• Note: The port-number set in remote_hosts should be the same as the one set in server.rmi.port in the Slave(s)
• Next, again bring up a console and go to this 'bin' directory and type 'jmeter.bat' (in case of a Windows System) or just 'jmeter' (in case of a *NIX System)

This will bring up the JMeter GUI of the Master instance from which the Slaves can be made to run by either doing a:

• Run -> Remote Start -> Choosing the desired Slave OR
• Run -> Remote Start All

And that's it, different loads maybe set on each Slave from the Master GUI. :)

NIO (Non-Blocking IO) and Asynchronous Calls

Came across the term NIO (introduced in Java 4, Java 7 has rolled out NIO2) in a recent project requirement. To me, there was a very thin line of difference in the concepts of having a REST Client use NIO vs. Asynchronous calls. Googling on the net did not provide a very succinct result either. Hence, based on the knowledge gathered here's the summary:

* Asynchronous implies non-real time. Imagine your newspaper-boy; he just drops the paper and goes off to the next house to deliver without waiting for you to open up and hand it over to you. That's asynchronous. Unlike the earlier times milkman who rings the bell and keeps waiting for you to appear with a container and collect the milk; which is synchronous.

*NIO - well, think of it as collecting stuff into a buffer and then taking from it. Imagine a water tap. People do not take drops from the tap; rather it is collected in some bucket or mug et al, that is buffered and then used. Just that the water in the bucket in terms of NIO happens to be the data we are interested in reading from or writing to. Hence, the use of 'buffers' in NIO.


So how does the above sit in terms of REST Client? Well, we were mainly bothered with Jersey Clients. Just note that Jersey also provides Synchronous and Asynchronous Clients. But neither are NIO. The API states it. But interestingly, Jersey has this feature of allowing the use of different Connectors (at Transport Layer). And one of these, namely GrizzlyConnectorProvider uses NIO at the Transport Layer which can be used with both Synchronous and Asynchronous Clients.

Ref# GrizzlyConnectorProvider


Aah, this is a rather short piece but the time spent in crunching out just these few facts did take us quite a while! ;)