Limit the Number of Threads
Your hardware's capabilities will limit the number of threads you can effectively run with JMeter. It will also depend on how fast your server. The more JMeter works, the less accurate its timing information may become. The more work JMeter does, the more each thread has to wait to get access to the CPU, the more inflated the timing information gets. If you need large-scale load testing, consider running multiple non-GUI JMeter instances on multiple machines. For testing how JMeter performs on a given platform, the Java Test sampler can be used.Using Cookie Manager
The HTTP Cookie Manager element has three functions:1.The cookie manager stores and sends cookies just like a web browser.
If you have an HTTP Request and the response contains a cookie, the Cookie Manager automatically stores that cookie and will use it for all future requests to that particular web site. Each JMeter thread has its own "cookie storage area". So, if you are testing a web site that uses a cookie for storing information for particular sessions then each JMeter thread will have its own session.
2. Received Cookies can be stored as JMeter thread variables.
To save cookies as variables, define the property "CookieManager.save.cookies=true”. The names of the cookies contain the prefix "COOKIE_" before they are stored (this avoids accidental corruption of local variables). To revert to the original behavior, define the property "CookieManager.name.prefix= " (with one or more spaces). If enabled, the value of a cookie with the name TEST can be referred to as ${COOKIE_TEST}.
3. Manually add a cookie to the Cookie Manager.
Note that if you do this, the cookie will be shared by all JMeter threads. Such cookies are created with an expiration date far in the future.
Using the Authorization Manager
The Authorization Manager lets you specify one or more user logins for web pages that are restricted using server authentication. You see this type of authentication when you use your browser to access a restricted page, and your browser displays a login dialog box. JMeter transmits the login information when it encounters this type of page.
Base URL: A partial or complete URL that matches one or more HTTP Request URLs.
Username: The username to authorize.
Password: The password for the user.
Domain: The domain to use for NTLM.
Realm: The realm to use for NTLM.
Controls:
Add Button: Add an entry to the authorization table.
Delete Button: Delete the currently selected table entry.
Load Button: Load a previously saved authorization table and add the entries to the existing authorization table entries.
Save As Button: Save the current authorization table to a file.
Reducing resource requirements
Some suggestions on reducing resource usage- Use non-GUI mode: jmeter -n -t test.jmx -l test.jtl
- Use as few Listeners as possible; if using the -l flag as above they can all be deleted or disabled.
- Don't use "View Results Tree" or "View Results in Table" listeners during the load test; use them only during scripting phase to debug your scripts.
- Rather than using lots of similar samplers, use the same sampler in a loop, and use variables (CSV Data Set) to vary the sample. Or perhaps use the Access Log Sampler.
- Don't use functional mode
- Use CSV output rather than XML
- Only save the data that you need
- Use as few Assertions as possible
If your test needs large amounts of data particularly if it needs to be randomizedcreate the test data in a file that can be read with CSV Dataset. This avoids wasting resources at run-time.
Bean Shell Server
The Bean Shell interpreter has a very useful feature it can act as a server, which is accessible by telnet or http.If you do wish to use the server, define the following in jmeter.properties:
beanshell.server.port=9000
beanshell.server.file=../extras/startup.bsh
In the above example, the server will be started, and will listen on ports 9000 and 9001. Port 9000 will be used for http access. Port 9001 will be used for telnet access. The startup.bsh file will be processed by the server, and can be used to define various functions and set up variables. The startup file defines methods for setting and printing JMeter and system properties. This is what you should see in the JMeter console:
Startup script running
Startup script completed
Httpd started on port: 9000
Sessiond started on port: 9001
Distributed Testing
In the event that your JMeter client machine is unable, performance-wise, to simulate enough users to stress your server, an option exists to control multiple, remote JMeter engines from a single JMeter GUI client. By running JMeter remotely, you can replicate a test across many low-end computers and thus simulate a larger load on the server. One instance of the JMeter GUI client can control any number of remote JMeter instances, and collect all the data from them. This offers the following features:
Saving of test samples to the local machine
Management 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
However, remote mode does use more resources than running the same number of non-GUI tests independently. If many server instances are used, the client JMeter can become overloaded, as can the client network connection.
Step 1: Configure the nodes
Make sure that all the nodes (client and servers) are running exactly the same version of JMeter. If the test uses any data files, note that these are not sent across by the client so make sure that these are available in the appropriate directory on each server. If necessary you can define different values for properties by editing the user.properties or system.properties files on each server. These properties will be picked up when the server is started and may be used in the test plan to affect its behavior (e.g. connecting to a different remote server). Alternatively use different content in any data files used by the test (e.g. if each server must use unique ids, divide these between the data files).
Step 2: 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.
Note that there can only be one JMeter server on each node unless different RMI ports are used.
Step 3: Add the server IP to your client's Properties File
Edit the properties file on the controlling JMeter machine. In /bin/jmeter.properties, find the property named, "remote hosts", and add the value of your running JMeter server's IP address. Multiple such servers can be added, comma-delimited.
Note that you can use the -R command line option instead to specify the remote host(s) to use. This has the same effect as using -r and -Jremote_hosts={serverlist}
If you define the JMeter property server.exitaftertest=true, then the server will exit after it runs a single test.
Step 4: Start the JMeter Client from a GUI client
Now you are ready to start the controlling JMeter client. For MS-Windows, start the client with the script "bin/jmeter.bat". For UNIX, use the script "bin/jmeter". You will notice that the Run menu contains two new sub-menus: "Remote Start" and "Remote Stop" (see figure 1). These menus contain the client that you set in the properties file. Use the remote start and stop instead of the normal JMeter start and stop menu items.
Distributed Testing
Distributed Testingv