Now, let's get up and running with JMeter, beginning with its installation.
JMeter comes as a bundled archive so it is super easy to get started with it. Those working in corporate environments behind a firewall or machines with non-admin privileges appreciate this more. To get started, grab the latest binary release by pointing your browser to http://jmeter.apache.org/download_jmeter.cgi. At the time of writing this, the current release version is 2.12. The download site offers the bundle as both .zip file and .tar file. In this book, we go with the .zip file option, but free feel to download the .tgz file if that's your preferred way of grabbing archives.
Once downloaded, extract the archive to a location of your choice. Throughout this book, the location you extracted the archive to will be referred to as JMETER_HOME.
Provided you have a JDK/JRE correctly installed and a JAVA_HOME environment variable set, you are all set and ready to run!
The following screenshot shows a trimmed down directory structure of a vanilla JMeter install:
JMETER_HOME folder structure
Following are some of the folders in the Apache-JMeter-2.12 as shown in the preceding screenshot:
bin: This folder contains executable scripts to run and perform other operations in JMeterdocs: This folder contains a well-documented user guideextras: This folder contains miscellaneous items including samples illustrating the usage of the Apache Ant build tool (http://ant.apache.org/) with JMeter and bean shell scriptinglib: This folder contains utility JAR files needed by JMeter (you may add additional JARs here to use from within JMeter—more on this will be covered later)
Follow these steps to install Java JDK:
Go to http://www.oracle.com/technetwork/java/javase/downloads/index.html.
Download Java JDK (not JRE) compatible with the system that you will use to test. At the time of writing, JDK 1.8 (update 20) was the latest and that is what we use throughout this book.
Double-click on the executable and follow the on-screen instructions.
Note
On Windows systems, the default location for the JDK is under
Program Files. While there is nothing wrong with this, the issue is that the folder name contains a space, which can sometimes be problematic when attempting to set PATH and run programs such as JMeter depending on the JDK from the command line. With this in mind, it is advisable to change the default location to something such asC:\tools\jdk.
Here are the steps to set up the JAVA_HOME environment variable on Windows and Unix operating systems.
For illustrative purposes, assume that you have installed Java JDK at /opt/tools/jdk:
Open up a terminal window.
Export
JAVA_HOME=/opt/tools/jdk.Export
PATH=$PATH:$JAVA_HOME.
It is advisable to set this in your shell profile settings such as .bash_profile (for bash users) or .zshrc (for zsh users) so you won't have to set it for each new terminal window you open.
Once installed, the
bin folder under the JMETER_HOME folder contains all the executable scripts that can be run. Based on the operating system that you installed JMeter on, you either execute the shell scripts (.sh file) for operating systems that are Unix/Linux flavored, or their batch (.bat file) counterparts on operating systems that are Windows flavored.
Tip
JMeter files are saved as XML files with a .jmx extension. We refer to them as test scripts or JMX files in this book.
jmeter.sh: This script launches JMeter GUI (the default)jmeter-n.sh: This script launches JMeter in non-GUI mode (takes a JMX file as input)jmeter-n-r.sh: This script launches JMeter in non-GUI mode remotelyjmeter-t.sh: This opens a JMX file in the GUIjmeter-server.sh: This script starts JMeter in server mode (this will be kicked off on the master node when testing with multiple machines remotely; more on this in Chapter [x])mirror-server.sh: This script runs the mirror server for JMetershutdown.sh: This script gracefully shuts down a running non-GUI instancestoptest.sh: This script abruptly shuts down a running non-GUI instance
To start JMeter, open a terminal shell, change to the JMETER_HOME/bin folder and run the following command on Unix/Linux:
./jmeter.sh
Run the following command on Windows:
jmeter.bat
A short moment later, you will see the JMeter GUI displayed in the Configuring proxy server section. Take a moment to explore the GUI. Hover over each icon to see a short description of what it does. The Apache JMeter team has done an excellent job with the GUI. Most icons are very similar to what you are used to, which helps ease the learning curve for new adapters. Some of the icons, for example, stop and shutdown, are disabled for now till a scenario/test is being conducted. In the next chapter, we will explore the GUI in more detail as we record our first test script.
On the terminal window, you might see some warnings from Java 8 that some Java options (PermSize and MaxPerSize) provided will be ignored. Do not be alarmed. JDK 8 came with better memory management and some default Java options used to start JMeter are no longer required, so it ignores them. You can read more about this at the following links:
http://java.dzone.com/articles/java-8-permgen-metaspace
http://www.infoq.com/news/2013/03/java-8-permgen-metaspace
Tip
The environment variable JVM_ARGS can be used to override JVM settings in the jmeter.bat or jmeter.sh script. Consider the following example:
export JVM_ARGS="-Xms1024m -Xmx1024m -Dpropname=propvalue"
Running JMeter with incorrect options provides you with usage info. The options provided are as follows:
./jmeter.sh –
-h, --help print usage information and exit -v, --version print the version information and exit -p, --propfile<argument> thejmeter property file to use -q, --addprop<argument> additionalJMeter property file(s) -t, --testfile<argument> thejmeter test(.jmx) file to run -l, --logfile <argument> the file to log samples to -j, --jmeterlogfile<argument> jmeter run log file (jmeter.log) -n, --nongui run JMeter in nongui mode
This is a snippet (non-exhaustive list) of what you might see if you did the same. We will explore some, but not all these options as we go through the book.
Since JMeter is 100 percent pure Java, it comes packed with functionality to get most of the test cases scripted. However, there might come a time when you need to pull in a functionality provided by a third-party library or one developed by yourself, which is not present by default. As such, JMeter provides two directories where such third-party libraries can be placed to be auto discovered on its classpath:
JMETER_HOME/lib: This is used for utility JARs.JMETER_HOME/lib/ext: This is used for JMeter components and add-ons. All custom-developed JMeter components should be placed in thelib/extfolder, while third-party libraries (JAR files) should reside in thelibfolder.
If you are working from behind a corporate firewall, you may need to configure JMeter to work with it, providing it with the proxy server host and port number. To do so, supply additional command-line parameters to JMeter when starting it up. Some of them are as follows:
-H: This command-line parameter specifies the proxy server hostname or IP address-P: This specifies the proxy server port-u: This specifies the proxy server username if it is secure-a: This specifies the proxy server password if it is secure, for example:./jmeter.sh -H proxy.server –P 7567 -u username -a password
On Windows, run the jmeter.bat file instead.
Tip
Do not confuse the proxy server mentioned here with JMeter's built-in HTTP Proxy Server, which is used to record HTTP or HTTPS browser sessions. We will be exploring this in the next chapter when we record our first test scenario.
The screen is displayed as follows:
JMeter GUI
As described earlier, JMeter can run in non-GUI mode. This is needed when you run remotely, or want to optimize your testing system by not taking the extra overhead cost of running the GUI. Normally, you will run the default (GUI) when preparing your test scripts and running light load, but run the non-GUI mode for higher loads.
To do so, use the following command-line options:
-n: This command-line option indicates to run in non-GUI mode-t: This command-line option specifies the name of the JMX test file-l: This command-line option specifies the name of the JTL file to log results to-j: This command-line option specifies the name of the JMeter run log file-r: This command-line option runs the test servers specified by theremote_hostsJMeter property-R: This command-line option runs the test in the specified remote servers (for example,-Rserver1,server2)
In addition, you can also use the -H and -P options to specify proxy server host and post like we saw earlier:
./jmeter.sh -n -t test_plan_01.jmx -l log.jtl
This is used when performing distributed testing, that is, using more testing servers to generate additional load on your system. JMeter will be kicked off in server mode on each remote server (slave) and then a GUI on the master server will be used to control the slave nodes. We will discuss this in detail when we dive into distributed testing in Chapter 4, Managing Sessions:
./jmeter-server.sh
JMeter provides two ways to override Java, JMeter, and logging properties. One way is to directly edit the jmeter.properties, which resides in the JMETER_HOME/bin folder. I suggest that you take a peek into this file and see the vast number of properties you can override. This is one of the things that makes JMeter so powerful and flexible. On most occasions, you will not need to override the defaults, as they have sensible default values.
The other way to override these values is directly from the command line when starting JMeter.
The options available to you include:
Defining a Java system property value:
-D<property name>=<value>Defining a local JMeter property:
-J<property name>=<value>
Defining a JMeter property to be sent to all remote servers:
-G<property name>=<value>
Defining a file containing JMeter properties to be sent to all remote servers:
-G<property file>
Overriding a logging setting, setting a category to a given priority level:
-L<category>=<priority> ./jmeter.sh -Duser.dir=/home/bobbyflare/jmeter_stuff \ -Jremote_hosts=127.0.0.1 -Ljmeter.engine=DEBUG
JMeter keeps track of all errors that occur during a test in a log file named jmeter.log by default. The file resides in the folder from which JMeter was launched. The name of this log file, like most things, can be configured in jmeter.properties or via a command-line parameter -j <name_of_log_file>. When running the GUI, the error count is indicated in the top-right corner, that is, to the left of the number of threads running for the test, as shown in Figure 1.4 in the following screenshot. Clicking on it reveals the log file contents directly at the bottom of the GUI. The log file provides an insight into what exactly is going on in JMeter when your tests are being executed and helps determine the cause of error(s) when they occur.
Figure 1.4: JMeter GUI error count/indicator
Should you need to customize JMeter default values, you can do so by editing the jmeter.properties file in the JMETER_HOME/bin folder, or making a copy of that file, renaming it to something different (for example, my-jmeter.properties), and specifying that as a command-line option when starting JMeter.
Some options you can configure include:
xml.parser: This specifies Custom XML parser implementation. The default value isorg.apache.xerces.parsers.SAXParser. It is not mandatory. If you found the provided SAX parser buggy for some of your use cases, it provides you with the option to override it with another implementation. For example, you can usejavax.xml.parsers.SAXParser, provided that the right JARs exist on your instance of JMeter classpath.remote_hosts: This is a comma-delimited list of remote JMeter hosts (orhost:portif required). When running JMeter in a distributed environment, list the machines where you have JMeter remote servers running. This will allow you to control those servers from this machine's GUI. This applies only to distributed testing and is not mandatory. More on this will be discussed in Chapter 6, Distributed Testing.not_in_menu: This is a list of components you do not want to see in JMeter's menus. Since JMeter has quite a number of components, you may wish to restrict it to show only components you are interested in or those you use regularly. You may list their classname or their class label (the string that appears in JMeter's UI) here, and they will no longer appear in the menus. The defaults are fine and in our experience, we have never had to customize them, but we list it here so that you are aware of its existence. It is not mandatory.user.properties: This specifies the name of the file containing additional JMeter properties. These are added after the initial property file, but before the-qand-Joptions are processed. This is not mandatory. User properties can be used to provide additional classpath configurations such as plugin paths via thesearch_pathsattribute, and utility JAR paths via theuser_classpathattribute. In addition, these properties files can be used to fine-tune JMeter components' log verbosity.search_paths: This specifies a list of paths (separated by;) that JMeter will search for JMeter add-on classes; for example additional samplers. This is in addition to any of the JARs found in thelib/extfolder. This is not mandatory. This comes in handy, for example, when extending JMeter with additional plugins that you don't intend to install in theJMETER_HOME/lib/extfolder. You can use this to specify an alternate location on the machine to pick up the plugins. Refer to Chapter 4, Managing Sessions.user.classpath: In addition to JARs in thelibfolder, use this attribute to provide additional paths that JMeter will search for utility classes. It is not mandatory.
system.properties: This specifies the name of the file containing additional system properties for JMeter to use. These are added before the-Sand-Doptions are processed. This is not mandatory. This typically provides you with the ability to fine-tune various SSL settings, key stores, and certificates.ssl.provider: This specifies the custom SSL implementation if you don't want to use the built-in Java implementation. This is not mandatory. If, for some reason, the default built-in Java implementation of SSL, which is quite robust, doesn't meet your particular usage scenario, this allows you to provide a custom one. In our experience, the default has always been sufficient.
The command-line options are processed in the following order:
-p profile: This specifies the customjmeter propertiesfile to be used. If present, it is loaded and processed. This is optional.jmeter.propertiesfile: This is the default configuration file for JMeter and is already populated with sensible default values. It is loaded and processed after any user-provided custom properties file.-j logfile: This is optional. It specifies thejmeterlogfile. It is loaded and processed after thejmeter.propertiesfile that we discussed previously.user.properties: is loaded (if any).system.properties: is loaded (if any).All other command-line options are processed.