Configuring the master node

Now that we have one slave node configured, we can test it out by configuring the master node to connect to it and control it. To do that, we will have to add the slave node's IP address to the master's node configuration file.

On the host machine (where the JMeter GUI client is running), perform the following steps:

  1. Open JMETER_HOME/bin/jmeter.properties.
  2. Look for the line beginning with remote_hosts=127.0.0.1.
  3. Change it to remote_hosts=172.28.128.3.
  4. 172.28.128.3 should be changed to match the assigned IP address of your virtual box.
  5. Save the file.
  6. Launch JMeter.
  7. Navigate to Run | Remote Start | Slave IP address (where Slave IP address is the assigned IP address of your virtual machine).

By clicking on the Slave IP address, the master node will make a connection with the remote server running on the VirtualBox. You will see a similar log on the client and the server, respectively:

Remote Start menu

On the JMeter GUI client console:

Using remote object: UnicastRef [liveRef: [endpoint:[172.28.128.3:60883](remote),objID:[-7854a167:14b16e354ea:-7fff, 2799922095106363247]]]

On the JMeter server console:

Starting the test on host 172.28.128.3 @ Wed Jun 21 06:06:14 UTC 2017 (1498025174277)
Finished the test on host 172.28.128.3 @ Wed Jun 21 06:06:14 UTC 2017 (1498025174609)

Congratulations! We are now able to control this slave node from the master. We can proceed with testing at this point, but since we are focusing on distributed testing in this chapter, it will help to have two or more nodes to control.

Repeat the same steps we used to configure node_one to spin-off two more nodes: node_two and node_three. To spin-off the second and third slave machines, run vagrant up n2 and vagrant up n3, respectively. Once the machines are up, add their assigned IP addresses to jmeter.properties of the master node, like we did for node_one. In the end, we should have three slave nodes, which we can now control from the master node.

Now your JMeter GUI client should have three server IP addresses under Run | Remote Start, and you can either kick-off an individual server node by targeting the server IP address of choice, or start all the configured slave nodes at once by navigating to Run | Remote Start All (Command + Shift + R on the Mac or Ctrl + Shift + R on Windows). When starting all the configured node servers, if everything has been properly configured, you should see logs similar to the following on the master console with each server node responding and acknowledging, kicking off the intended test plan:

Using remote object: UnicastRef [liveRef: [endpoint:[ 172.28.128.3:60883](remote),objID:[49a18727:13da4a8a955:-7fff, -4630561463080329291]]]Using remote object: UnicastRef [liveRef: [endpoint:[ 172.28.128.5:51200](remote),objID:[46a1e04c:13da4a79d3d:-7fff, -5213066472819797239]]]Using remote object: UnicastRef [liveRef: [endpoint:[ 172.28.128.6:51791](remote),objID:[-1434b37d:13da4a85f8a:-7fff, -2658534524006849789]]]

As you can see from the preceding logs, the master node makes a connection with all the three configured slave nodes: 172.28.128.3, 172.28.128.5, and 172.28.128.6. With the connections verified, we can now pick a test plan to run and gather the results on the master node.

For our first test, we will execute a test that doesn't require input data. The provided test plan (https://raw.githubusercontent.com/ptwj/ptwj-code/master/chap6/browse-apple-itunes.jmx) navigates to Apple's iTunes website and browses around a bit for music, movies, apps, and so on. It does no data entry and therefore doesn't need any input data. Load that into the master node's JMeter GUI and kick it off on all slave nodes. The script launches 150 users over 30 seconds and runs for two iterations. Since we are distributing this over three slave nodes, we will have a total of 450 users launched (150 users per node) and 15 users started per second, that is, 450/30. The following screenshot shows the results our machine produced. It's a quad-core MacBook Pro with a 2.2GHz processor and 8 GB of RAM. Your mileage may vary depending on the computing power of your machine:

Aggregate report for Browse Apple iTunes distributed test
It should be noted that, in our case, we are still running all these virtual slave nodes on a single box, so the resources are still limited, that is, all the slaves are still sharing the resources of the host machine. Therefore, attempting to distribute more load than what can be originally handled by the host machine can lead to degraded performance with high response times. However, nothing prevents you from running the provided Vagrant scripts on additional physical machines to simulate more load without worrying about constrained resources.

The second test is the one we saw earlier, in Chapter 2, Recording Your First Test. It's the Excilys' banking application that requires an input data file. As JMeter only sends the test plans to slave nodes, we need to get the input files across to all slave nodes in order to successfully execute the test. To do that, perform the following steps:

  1. On the command line, go to the directory of the slave node.
  2. Run the following commands in sequence:
    • SSH into the machine:
vagrant ssh
  1. Go to the JMeter bin directory:
cd apache-jmeter-3.2/bin
  1. Get the users2.txt file from a remote location:
wget https://raw.github.com/berinle/vagrant-data/master/users2.txt

Repeat the steps for all three nodes. This puts the users2.txt file, which is needed by the test plan, in a location that can be seen by the JMeter server on the slave nodes. Now, open the test plan (excilys-bank-scenario-2.jmx) on the master JMeter GUI client. As earlier, select Run | Remote Start All. Feel free to increase the number of threads, ramp-up, and iterations, but be careful not to crash the server.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.188.152.162