How Do I Change Input Data For Multiple Users For Jmeter Load Testing

13. Remote Testing

In the issue that your JMeter customer machine is unable, performance-wise, to simulate enough users to stress your server or is limited at network level, an option exists to command multiple, remote JMeter engines from a single JMeter client. By running JMeter remotely, y'all tin replicate a test across many low-finish computers and thus simulate a larger load on the server. One instance of the JMeter client can command any number of remote JMeter instances, and collect all the information from them. This offers the following features:

Saving of test samples to the local auto
Direction of multiple JMeterEngines from a single machine
No need to copy the test plan to each server - the client sends it to all the servers

Note: The same examination plan is run by all the servers. JMeter does not distribute the load betwixt servers, each runs the full test plan. So if yous ready k Threads and have 6 JMeter server, you lot end up injecting 6000 Threads.

However, remote mode does employ more than resource than running the aforementioned number of CLI mode tests independently. If many server instances are used, the customer JMeter can become overloaded, as can the client network connection. This has been improved by switching to Stripped modes (come across below) but you should always bank check that your customer is not overloaded.

Notation that while you lot tin execute the JMeterEngine on your awarding server, you demand to be mindful of the fact that this will be calculation processing overhead on the awarding server and thus your testing results will be somewhat tainted. The recommended approach is to have ane or more machines on the same Ethernet segment as your application server that yous configure to run the JMeter Engine. This will minimize the impact of the network on the exam results without impacting the operation of the application server itself.

Footstep 0: Configure the nodes

Brand sure that all the nodes (client and servers) :

are running exactly the aforementioned version of JMeter.
are using the aforementioned version of Java on all systems. Using different versions of Java may work but is discouraged.
have a valid keystore for RMI over SSL, or you take disabled the use of SSL.

If the test uses any data files, note that these are non sent across past the customer so make certain that these are bachelor in the advisable directory on each server. If necessary yous can define different values for properties past editing the user.properties or system.properties files on each server. These backdrop volition exist picked upwardly when the server is started and may be used in the test programme to affect its behaviour (e.one thousand. connecting to a different remote server). Alternatively use different content in any datafiles used by the examination (e.thou. if each server must employ unique ids, divide these between the data files)

Step ane: Start the servers

To run JMeter in remote node, start the JMeter server component on all machines you wish to run on by running the JMETER_HOME/bin/jmeter-server (unix) or JMETER_HOME/bin/jmeter-server.bat (windows) script.

Annotation that there can only exist one JMeter server on each node unless different RMI ports are used.

The JMeter server application starts the RMI registry itself; there is no need to get-go RMI registry separately.

Past default, RMI uses a dynamic port for the JMeter server engine. This tin can crusade problems for firewalls, so you can define the JMeter property server.rmi.localport to control this port number. it will be used every bit the local port number for the server engine.

Stride 2: Add the server IP to your client'due south Properties File

Edit the properties file on the controlling JMeter machine. In JMETER_HOME/bin/jmeter.backdrop, discover the property named "remote_hosts" and add together the value of your running JMeter server's IP address. Multiple such servers tin exist added, comma-delimited.

Note that you can use the -R command line choice instead to specify the remote host(s) to use. This has the same consequence as using -r and -Jremote_hosts={serverlist}. Due east.g.

jmeter -Rhost1,127.0.0.one,host2

If you define the JMeter property server.exitaftertest=true, so the server volition go out after it runs a single examination. See also the -X flag (described beneath)

Step 3a: Start the JMeter Client from a GUI client to check configuration

Now you are ready to offset the decision-making JMeter client. For MS-Windows, first the client with the script "bin/jmeter.bat". For UNIX, use the script "bin/jmeter". You will notice that the Run bill of fare contains two new sub-menus: "Remote Start" and "Remote End" (run across figure 1). These menus contain the client that yous prepare in the backdrop file. Employ the remote showtime and stop instead of the normal JMeter start and stop menu items.

Figure 1 - Run Menu — Effigy one - Run Menu

Stride 3b: Showtime the JMeter from a CLI mode Client

GUI mode should only be used for debugging, every bit a better alternative, you should start the examination on remote server(southward) from a CLI mode (command-line) client. The control to exercise this is:

jmeter -northward -t script.jmx -r

jmeter -n -t script.jmx -R server1,server2,…

Other flags that may be useful:

-Gproperty=value: define a property in all the servers (may announced more once)
-Ten: Go out remote servers at the end of the exam.

The first case will first the exam on any servers are defined in the JMeter property remote_hosts;
The second example volition define remote_hosts from the list of servers and then first the test on the remote servers.
The command-line customer volition leave when all the remote servers take stopped.

13.one Setting up SSL¶

Since JMeter four.0 the default transport machinery for RMI volition use SSL. SSL needs keys and certificates to work. You volition have to create those keys yourself.

The simplest setup is to use one key/cert pair for all JMeter servers and clients yous want to connect. JMeter comes with a script to generate a keystore that contains one fundamental (and its corresponding document) named rmi. The script is located in the bin directory and is available for Windows systems (called bin/create-rmi-keystore.bat) and Unix like systems (chosen bin/create-rmi-keystore.sh). Information technology volition generate a central-pair, that is valid for seven days, with a default passphrase of value 'changeit'. It is advised to call it from within the bin directory.

When you run the script, it will ask y'all some questions about some names it will embed in the document. You can type in any you desire, as long the keystore tool accepts it. That value has to match the holding server.rmi.ssl.keystore.alias, which defaults to rmi. A sample session to create the keystore is shown beneath.

$ cd jmeter/bin $ ./create-rmi-keystore.sh What is your first and concluding proper noun?   [Unknown]:  rmi What is the proper name of your organizational unit?   [Unknown]:  My unit of measurement proper noun What is the name of your organization?   [Unknown]:  My organization name What is the name of your City or Locality?   [Unknown]:  Your Urban center What is the name of your State or Province?   [Unknown]:  Your State What is the two-letter country code for this unit of measurement?   [Unknown]:  XY Is CN=rmi, OU=My unit proper name, O=My organisation proper noun, L=Your City, ST=Your State, C=XY correct?   [no]:  yeah  Copy the generated rmi_keystore.jks to jmeter/bin folder or reference it in property 'server.rmi.ssl.keystore.file'

The defaults settings for RMI should work with this setup. Copy the file bin/rmi_keystore.jks to every JMeter server and client you want to use for your distributed testing setup.

xiii.2 Doing information technology Manually¶

In some cases, the jmeter-server script may non work for you (if you are using an Os platform not predictable by the JMeter developers). Here is how to start the JMeter servers (step 1 in a higher place) with a more than manual procedure:

Pace 1a: Start the RMI Registry

Since JMeter 2.3.1, the RMI registry is started past the JMeter server, so this section does not apply in the normal case. To revert to the previous behaviour, define the JMeter belongings server.rmi.create=false on the server host systems and follow the instructions below.

JMeter uses Remote Method Invocation (RMI) as the remote communication mechanism. Therefore, you need to run the RMI Registry application (which is named "rmiregistry") that comes with the JDK and is located in the "bin" directory. Before running rmiregistry, brand sure that the post-obit jars are in your arrangement classpath:

JMETER_HOME/lib/ext/ApacheJMeter_core.jar
JMETER_HOME/lib/jorphan.jar
JMETER_HOME/lib/logkit-ii.0.jar

The rmiregistry awarding needs access to sure JMeter classes. Run rmiregistry with no parameters. Past default the application listens to port 1099.

Step 1b: Kickoff the JMeter Server

Once the RMI Registry application is running, starting time the JMeter Server. Use the "-southward" pick with the jmeter startup script ("jmeter -s").

Steps 2 and 3 remain the aforementioned.

xiii.iii Tips¶

JMeter/RMI requires a connection from the customer to the server. This will use the port you lot chose, default 1099.
JMeter/RMI besides requires a contrary connection in gild to render sample results from the server to the client.
These will use loftier-numbered ports.
These ports can be controlled past jmeter holding called client.rmi.localport in jmeter.backdrop.
If this is not-cypher, it volition exist used as the base for local port numbers for the client engine. At the moment JMeter will open up to three ports get-go with the port defined in client.rmi.localport. If there are any firewalls or other network filters between JMeter client and server, yous will demand to make certain that they are set up to permit the connections through. If necessary, employ monitoring software to show what traffic is existence generated.

If you're running Suse Linux, these tips may assistance. The default installation may enable the firewall. In that case, remote testing will non work properly. The following tips were contributed by Sergey 10.

If you see connections refused, turn on debugging by passing the following options.

rmiregistry -J-Dsun.rmi.log.debug=true \      -J-Dsun.rmi.server.exceptionTrace=truthful \      -J-Dsun.rmi.loader.logLevel=verbose \      -J-Dsun.rmi.dgc.logLevel=verbose \      -J-Dsun.rmi.ship.logLevel=verbose \      -J-Dsun.rmi.transport.tcp.logLevel=verbose \

Since JMeter 2.3.1, the RMI registry is started by the server; notwithstanding the options can still be passed in from the JMeter control line. For instance: "jmeter -due south -Dsun.rmi.loader.logLevel=verbose" (i.e. omit the -J prefixes). Alternatively the backdrop can exist defined in the system.backdrop file.

The solution to the trouble is to remove the loopbacks 127.0.0.1 and 127.0.0.2 from /etc/hosts. What happens is jmeter-server can't connect to rmiregistry if 127.0.0.2 loopback is not available. Use the following settings to set the problem.

Replace

`dirname $0`/jmeter  -s "$@"

With

HOST="-Djava.rmi.server.hostname=[computer_name][computer_domain] \       -Djava.security.policy=`dirname $0`/[policy_file]" \ `dirname $0`/jmeter $HOST -s "$@"

Too create a policy file and add [computer_name][computer_domain] line to /etc/hosts.

In order to better back up SSH-tunneling of the RMI communication channels used in remote testing, since JMeter 2.half dozen:

a new property "client.rmi.localport" can be prepare to command the RMI port used past the RemoteSampleListenerImpl
To support tunneling RMI traffic over an SSH tunnel as the remote endpoint using a port on the local machine, loopback interface is now allowed to exist used if it has been specified directly using the Java Organization Property "java.rmi.server.hostname" parameter.

xiii.iv Using a different port¶

Past default, JMeter uses the standard RMI port 1099. It is possible to change this. For this to work successfully, all the following need to hold:

On the server, start rmiregistry using the new port number
On the server, kickoff JMeter with the property server_port defined
On the client, update the remote_hosts holding to include the new remote host:port settings

Since JMeter 2.1.1, the jmeter-server scripts provide support for irresolute the port. For case, assume y'all want to apply port 1664 (perhaps 1099 is already used).

On Windows (in a DOS box)

C:\JMETER> Set up SERVER_PORT=1664 C:\JMETER> JMETER-SERVER [other options]

On Unix:

$ SERVER_PORT=1664 jmeter-server [other options]

[Northward.B. use upper example for the surroundings variable]

In both cases, the script starts rmiregistry on the specified port, and then starts JMeter in server mode, having defined the "server_port" property.

The chosen port will be logged in the server jmeter.log file (rmiregistry does not create a log file).

xiii.5 Using a dissimilar sample sender¶

Listeners in the test program send their results back to the client JMeter which writes the results to the specified files Past default, samples are sent back synchronously as they are generated. This tin can bear upon the maximum throughput of the server examination; the sample upshot has to be sent back before the thread can continue. At that place are some JMeter properties that can be prepare to change this behaviour.

way

sample sending mode - default is StrippedBatch since two.ix. This should exist set on the customer node.

Standard

send samples synchronously as soon as they are generated

Concord

concord samples in an assortment until the end of a run. This may use a lot of memory on the server and is discouraged.

DiskStore

shop samples in a deejay file (nether java.io.temp) until the end of a run. The serialised data file is deleted on JVM get out.

StrippedDiskStore

remove responseData from successful samples, and use DiskStore sender to send them.

Batch

transport saved samples when either the count (num_sample_threshold) or fourth dimension (time_threshold) exceeds a threshold, at which point the samples are sent synchronously. The thresholds can be configured on the server using the post-obit properties:

num_sample_threshold: number of samples to accrue, default 100
time_threshold: fourth dimension threshold, default 60000 ms = sixty seconds

See as well the Asynch mode, described beneath.

Statistical

ship a summary sample when either the count or time exceeds a threshold. The samples are summarised by thread group proper name and sample label. The post-obit fields are accumulated:

elapsed time
latency
bytes
sample count
error count

Other fields that vary between samples are lost.

Stripped

remove responseData from successful samples

StrippedBatch

remove responseData from successful samples, and use Batch sender to send them.

Asynch

samples are temporarily stored in a local queue. A separate worker thread sends the samples. This allows the examination thread to continue without waiting for the upshot to be sent back to the client. However, if samples are existence created faster than they can be sent, the queue will eventually make full, and the sampler thread volition block until some samples can exist drained from the queue. This fashion is useful for smoothing out peaks in sample generation. The queue size can be adjusted past setting the JMeter property asynch.batch.queue.size (default 100) on the server node.

StrippedAsynch

remove responseData from successful samples, and use Async sender to send them.

Custom implementation

set the way parameter to your custom sample sender class name. This must implement the interface SampleSender and have a constructor which takes a single parameter of blazon RemoteSampleListener.

Stripped way family strips responseData and then this means that some Elements that rely on the previous responseData being available volition not work.
This is not really a trouble every bit there is ever a more efficient manner to implement this feature.

The following properties apply to the Batch and Statistical modes:

num_sample_threshold: number of samples in a batch (default 100)
time_threshold: number of milliseconds to look (default lx seconds)

13.6 Dealing with nodes that failed starting¶

For large-scale tests in that location is a chance that some part of remote servers volition be unavailable or down. For example, when you utilise automation script to allocate many cloud machines and use them equally generators, some of requested machines might fail booting because of cloud's issues. Since JMeter ii.13 in that location are new properties to control this behaviour.

First what you lot might want is to retry initialization attempts in hope that failed nodes just slightly delayed their kick. To enable retries, you should set customer.tries property to total number of connexion attempts. By default it does simply one attempt. To control retry delay, fix the client.retries_delay property to number of milliseconds to sleep between attempts.

Finally, yous might nonetheless want to run the test with those generators that succeeded initialization and skipping failed nodes. To enable that, set the client.continue_on_fail=true property.

xiii.7 Using a security-manager¶

When running JMeter in a distributed environment y'all take to be aware, that JMeter is basically a remote execution amanuensis on both the server and client side. This could be used past a malicious political party to gain further access, once it has compromised one of the JMeter clients or servers. To mitigate this Java has the concept of a security manager that gets asked by the JVM before potential dangerous actions are executed. Those actions could be resolving host names, creating or reading files or executing commands in the Os.

The security managing director can be enabled by setting the Java system properties java.security.manager and java.security.policy. Exist certain to accept a look at the Quick Bout of Decision-making Applications.

Using the new mechansism of setenv.sh (or setenv.bat under Windows) you can enable the security manager past adding the following code snippet to ${JMETER_HOME}/bin/setenv.sh:

JVM_ARGS=" \    -Djava.security.manager \    -Djava.security.policy=${JMETER_HOME}/bin/java.policy \    -Djmeter.domicile=${JMETER_HOME} \ "

The JVM will now add together the policies defined in the file ${JMETER_HOME}/bin/coffee.policy to the possibly globally defined policies. If y'all want your definition to be the merely source for policies, utilise two equal signs instead of one when setting the property coffee.security.policy.

The policies will be dependent upon your use case and it might take a while to find the correct restricted and allowed actions. Java can help you notice the needed policies with the belongings java.security.debug. Set up information technology to access and it will log all permissions, that it gets asked to permit. Simply add together the following line to your setenv.sh:

JVM_ARGS="${JVM_ARGS} -Djava.security.debug=access"

It might look a bit strange, that we define a Java system holding jmeter.home with the value of ${JMETER_HOME}. This variable will be used in the example java.policy to limit the file system access and allow it only to read JMeters configuration and libraries and restrict write admission to specific locations, but.

The post-obit policy definition file has been used for a unproblematic remote test. You will probably have to tweak the policies, when you run more complex scenarios. The exam plans are somewhere placed within the users habitation directory nether a directory called jmeter-testplans. The sample java.policy looks similar:

grant codeBase "file:${jmeter.home}/bin/*" {   permission java.security.AllPermission; };  grant codeBase "file:${jmeter.dwelling house}/lib/jorphan.jar" {   permission java.security.AllPermission; };  grant codeBase "file:${jmeter.home}/lib/log4j-api-two.11.ane.jar" {   permission java.security.AllPermission; };  grant codeBase "file:${jmeter.home}/lib/log4j-slf4j-impl-ii.11.1.jar" {   permission java.security.AllPermission; };  grant codeBase "file:${jmeter.dwelling house}/lib/slf4j-api-1.7.25.jar" {   permission java.security.AllPermission; };  grant codeBase "file:${jmeter.abode}/lib/log4j-core-two.11.1.jar" {   permission coffee.security.AllPermission; };  grant codeBase "file:${jmeter.home}/lib/ext/*" {   permission coffee.security.AllPermission; };  grant codeBase "file:${jmeter.domicile}/lib/httpclient-4.5.6.jar" {   permission java.net.SocketPermission "*", "connect,resolve"; };  grant codeBase "file:${jmeter.habitation}/lib/darcula.jar" {   permission java.lang.RuntimePermission "modifyThreadGroup"; };  grant codeBase "file:${jmeter.home}/lib/xercesImpl-2.12.0.jar" {   permission java.io.FilePermission "${java.habitation}/lib/xerces.backdrop", "read"; };  grant codeBase "file:${jmeter.home}/lib/dandy-all-2.4.15.jar" {   permission groovy.security.GroovyCodeSourcePermission "/smashing/script";   permission java.lang.RuntimePermission "accessClassInPackage.sunday.reflect";   permission java.lang.RuntimePermission "getProtectionDomain"; };  grant {   permission java.io.FilePermission "${jmeter.home}/backups", "read,write";   permission coffee.io.FilePermission "${jmeter.domicile}/backups/*", "read,write,delete";   permission java.io.FilePermission "${jmeter.home}/bin/upgrade.backdrop", "read";   permission coffee.io.FilePermission "${jmeter.home}/lib/ext/-", "read";   permission java.io.FilePermission "${jmeter.abode}/lib/ext", "read";   permission java.io.FilePermission "${jmeter.abode}/lib/-", "read";   permission java.io.FilePermission "${user.dwelling house}/jmeter-testplans/-", "read,write";   permission coffee.io.SerializablePermission "enableSubclassImplementation";   permission java.lang.reflect.ReflectPermission "suppressAccessChecks";   permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.dynalink.support";   permission java.lang.RuntimePermission "accessClassInPackage.sun.awt";   permission coffee.lang.RuntimePermission "accessClassInPackage.sun.misc";   permission coffee.lang.RuntimePermission "accessClassInPackage.sun.swing";   permission java.lang.RuntimePermission "accessDeclaredMembers";   permission java.lang.RuntimePermission "createClassLoader";   permission java.lang.RuntimePermission "createSecurityManager";   permission java.lang.RuntimePermission "getClassLoader";   permission java.lang.RuntimePermission "getenv.*";   permission coffee.lang.RuntimePermission "nashorn.createGlobal";   permission java.util.PropertyPermission "*", "read"; };

The usage of coffee.security.AllPermission is an easy way to make your examination plans work, but it might exist a dangerous shortcut on your path to security.