Vs-1120 Certified Jmeter Tester _Reading_Material

Certified Jmeter Tester VS-1120

V skills Certified Jmeter Tester

www.vskills.in Proficiency Testing Programme of

VS-1120

Intelligent Communication Systems India Limited

JV of DSIIDC ( Govt of NCT Delhi) & TCIL (Govt of India)

This document describes developing, executing and managing software tests using the Jmeter exam tool like FTP tests, Web tests, Database tests. etc This document is for beginners and intermediaries.

Certified - Jmeter Tester Training Material

Certified Jmeter Tester Copyright© 2014

Cubezoid Solutions Private Limited

Content, design, typesetting and published by Cubezoid Solutions Private Limited, [email protected]

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

All rights reserved This book is provided on the condition that it shall not by way of trade or otherwise, be lent, resold, hired out or otherwise circulated without the publisher’s prior consent in any form of binding or cover other than in which it is published and without a similar condition including this condition being imposed on the subsequent purchaser and without limiting the rights under the copyright reserved above, no part of this publication, may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying , recording or otherwise) without the prior permission of the copyright owner and publisher of the book

Disclaimer: Due care and diligence has been taken while editing and printing this book. Neither the Author, publisher nor the printer of the book holds any responsibility for any mistake that may have crept in inadvertently. Cubezoid Solutions Private Limited – the publishers, will be free from any liability for damages and loss of any nature arising out or related to the content. All disputes are subject to the jurisdiction of the competent courts in Delhi.

www.vskills.in

Page 2

Certified Jmeter Tester

TABLE OF CONTENTS 1. Introduction............................................................................................................................... 7 1.1. History................................................................................................................................................................7 1.2. The Future .........................................................................................................................................................7

2. Getting Started .......................................................................................................................... 8 2.1. Requirements .....................................................................................................................................................9 2.2. Optional .............................................................................................................................................................9 2.3. Installation ........................................................................................................................................................10 2.4. Running JMeter ................................................................................................................................................11 2.5. Configuring JMeter ...........................................................................................................................................18

3. Building a Test Plan................................................................................................................ 20 3.1. Adding and Removing Elements ......................................................................................................................20 3.2. Loading and Saving Elements ...........................................................................................................................20 3.3. Configuring Tree Elements ..............................................................................................................................20 3.4. Saving the Test Plan .........................................................................................................................................20 3.5. Running a Test Plan .........................................................................................................................................21 3.6. Error reporting .................................................................................................................................................22

4. Elements of a Test Plan .......................................................................................................... 23 4.1. ThreadGroup ...................................................................................................................................................23 4.2. Controllers........................................................................................................................................................24 4.3. Listeners ...........................................................................................................................................................26 4.4. Timers..............................................................................................................................................................26 4.5. Assertions .........................................................................................................................................................27 4.6. Configuration Elements ....................................................................................................................................27 4.7. Pre-Processor Elements....................................................................................................................................28 4.8. Post-Processor Elements ..................................................................................................................................28 4.9. Execution order................................................................................................................................................28 4.10. Scoping Rules .................................................................................................................................................29 4.11. Properties and Variables.................................................................................................................................31 4.12. Using Variables to parameterise tests..............................................................................................................31

5. Building a Web Test Plan....................................................................................................... 33 5.1. Adding Users....................................................................................................................................................33 5.2. Adding Default HTTP Request Properties ......................................................................................................34 5.3. Adding Cookie Support....................................................................................................................................36

www.vskills.in

Page 3

Certified Jmeter Tester 5.4. Adding HTTP Requests...................................................................................................................................36 5.5. Adding a Listener to View Store the Test Results .............................................................................................37 5.6. Logging in to a web-site.....................................................................................................................................38

6. Building an Advanced Web Test Plan .................................................................................. 40 6.1. Handling User Sessions With URL Rewriting ..................................................................................................40 6.2. Using a Header Manager ..................................................................................................................................40

7. Building a Database Test Plan ............................................................................................... 42 7.1. Adding Users....................................................................................................................................................42 7.2. Adding JDBC Requests ....................................................................................................................................43 7.3. Adding a Listener to View/Store the Test Results.............................................................................................46

8. Building an FTP Test Plan ..................................................................................................... 47 8.1. Adding Users....................................................................................................................................................47 8.2. Adding Default FTP Request Properties ..........................................................................................................48 8.3. Adding FTP Requests.......................................................................................................................................49 8.4. Adding a Listener to View/Store the Test Results.............................................................................................50

9. Building an LDAP Test Plan.................................................................................................. 52 9.1. Adding Users....................................................................................................................................................52 9.2. Adding Login Config Element..........................................................................................................................52 9.3. Adding LDAP Request Defaults.......................................................................................................................53 9.4. Adding LDAP Requests ...................................................................................................................................53 9.5. Adding a Listener to View/Store the Test Results.............................................................................................55 9.6. Building an Extended LDAP Test Plan............................................................................................................56 9.7. Adding Users....................................................................................................................................................57 9.8. Adding LDAP Extended Request Defaults.......................................................................................................58 9.9. Adding LDAP Requests ...................................................................................................................................58 9.10. Adding a Listener to View/Store the Test Results...........................................................................................65

10. Building a WebService Test Plan ........................................................................................ 66 10.1. Adding Users..................................................................................................................................................66 10.2. Adding WebService Requests.........................................................................................................................67

11. Building a JMS Point-to-Point Test Plan............................................................................ 70 11.1. Adding a Thread Group .................................................................................................................................70 11.2. Adding JMS Point-to-Point Sampler ...............................................................................................................71 11.3. Adding a Listener to View Store the Test Results ...........................................................................................71

12. Building a JMS Topic Test Plan .......................................................................................... 73 www.vskills.in

Page 4

Certified Jmeter Tester 12.1. Adding Users..................................................................................................................................................73 12.2. Adding JMS Subscriber and Publisher ...........................................................................................................74 12.3. Adding a Listener to View Store the Test Results ...........................................................................................76

13. Building a Monitor Test Plan............................................................................................... 78 13.1. Adding A Server .............................................................................................................................................78 13.2. HTTP Auth Manager.....................................................................................................................................78 13.3. Adding HTTP Request ..................................................................................................................................79 13.4. Adding Constant Timer..................................................................................................................................79 13.5. Adding a Listener to Store the Results............................................................................................................79 13.6. Adding Monitor Results..................................................................................................................................79

14. Introduction to listeners ....................................................................................................... 82 14.1. Default Configuration .....................................................................................................................................82 14.2. non-GUI (batch) test runs ...............................................................................................................................85 14.3. Resource usage ...............................................................................................................................................86 14.4. CSV Log format .............................................................................................................................................86 14.5. XML Log format 2.1 ......................................................................................................................................87 14.6. XML Log format 2.2 ......................................................................................................................................89 14.7. Sample Attributes ...........................................................................................................................................89 14.8. Saving response data .......................................................................................................................................89 14.9. Loading (reading) response data .....................................................................................................................89 14.10. Saving Listener GUI data..............................................................................................................................90

15. Remote Testing...................................................................................................................... 91 15.1. Doing it Manually ...........................................................................................................................................93 15.2. Tips ................................................................................................................................................................93 15.3. Using a different port......................................................................................................................................94 15.4. Using a different sample sender......................................................................................................................95

16. Best Practices......................................................................................................................... 97 16.1. Always use latest version of JMeter .................................................................................................................97 16.2. Limit the Number of Threads ........................................................................................................................97 16.3. Where to Put the Cookie Manager.................................................................................................................97 16.4. Where to Put the Authorization Manager ......................................................................................................97 16.5. User variables .................................................................................................................................................98 16.6. Reducing resource requirements ....................................................................................................................98 16.7. BeanShell server .............................................................................................................................................99 16.8. BeanShell scripting .......................................................................................................................................100

www.vskills.in

Page 5

Certified Jmeter Tester 16.9. Developing script functions in BeanShell, Javascript or Jexl etc. ...................................................................101 16.10. Parameterising tests.....................................................................................................................................101

17. Help! My boss wants me to load test our web app! ......................................................... 103 17.1. Questions to ask ...........................................................................................................................................103 17.2. Resources .....................................................................................................................................................103 17.3. Network........................................................................................................................................................103 17.4. Application ...................................................................................................................................................103 17.5. What platform should I use to run the benchmarks/load-tests ?...................................................................104 17.6. Tools ............................................................................................................................................................104 17.7. What other products are there ?...................................................................................................................105 17.8. Why Java ? ...................................................................................................................................................105

18. Functions.............................................................................................................................. 106 18.1. What can functions do..................................................................................................................................107 18.2. Where can functions and variables be used? ................................................................................................108 18.3. How to reference variables and functions .....................................................................................................108 18.4. The Function Helper Dialog ........................................................................................................................109 18.5. Functions ......................................................................................................................................................110

19. Regular Expressions ........................................................................................................... 128 19.1. Overview.......................................................................................................................................................128 19.2. Examples ......................................................................................................................................................128 19.3. Line mode ....................................................................................................................................................130 19.4. Meta characters.............................................................................................................................................130

20. Hints and Tips ..................................................................................................................... 132 20.1. Enabling Debug logging ................................................................................................................................132 20.2. Searching ......................................................................................................................................................132

www.vskills.in

Page 6

Certified Jmeter Tester

1. INTRODUCTION Apache JMeter is a 100% pure Java desktop application designed to load test client/server software (such as a web application). It may be used to test performance both on static and dynamic resources such as static files, Java Servlets, CGI scripts, Java objects, databases, FTP servers, and more. JMeter can be used to simulate a heavy load on a server, network or object to test its strength or to analyze overall performance under different load types. Additionally, JMeter can help you regression test your application by letting you create test scripts with assertions to validate that your application is returning the results you expect. For maximum flexibility, JMeter lets you create these assertions using regular expressions. But please note that JMeter is not a browser, it works at protocol level.

1.1. History Stefano Mazzocchi of the Apache Software Foundation was the original developer of JMeter. He wrote it primarily to test the performance of Apache JServ (a project that has since been replaced by the Apache Tomcat project). We redesigned JMeter to enhance the GUI and to add functionaltesting capabilities. JMeter became a Top Level Apache project in November 2011, which means it has a Project Management Commitee and a dedicated website.

1.2. The Future We hope to see JMeter's capabilities rapidly expand as developers take advantage of its pluggable architecture. The primary goal of further developments will be: Addition of Websocket protocol Addition of FTPS and SFTP protocols Enhancements to Webservices protocols (SOAP Attachments) Enhancements to JMS protocol implementation

www.vskills.in

Page 7

Certified Jmeter Tester

2. GETTING STARTED The easiest way to begin using JMeter is to first download the latest production release and install it. The release contains all of the files you need to build and run most types of tests, e.g. Web (HTTP/HTTPS), FTP, JDBC, LDAP, Java, JUnit and more. If you want to perform JDBC testing, then you will, of course, need the appropriate JDBC driver from your vendor. JMeter does not come with any JDBC drivers. JMeter includes the JMS API jar, but does not include a JMS client implementation. If you want to run JMS tests, you will need to download the appropriate jars from the JMS provider. Next, start JMeter and go through the Building a Test Plan section of the User Guide to familiarize yourself with JMeter basics (for example, adding and removing elements). Finally, go through the appropriate section on how to build a specific type of Test Plan. For example, if you are interested in testing a Web application, then see the section Building a Web Test Plan. The other specific Test Plan sections are: Advanced Web Test Plan JDBC FTP JMS Point-to-Point JMS Topic LDAP LDAP Extended WebServices (SOAP) Once you are comfortable with building and running JMeter Test Plans, you can look into the various configuration elements (timers, listeners, assertions, and others) which give you more control over your Test Plans.

Create Test Plan from Template You have the ability to create a new Test Plan from existing template. To do so you use the menu File > Templates... Templates or Templates icon:

Templates icon item

A popup appears, you can then choose a template among the list:

www.vskills.in

Page 8

Certified Jmeter Tester

Templates popup

A documentation for each template explains what to do once test plan is created from template.

2.1. Requirements JMeter requires your computing environment meets some minimum requirements.

Java Version JMeter requires a fully compliant JVM 6 or higher. Because JMeter uses only standard Java APIs, please do not file bug reports if your JRE fails to run JMeter because of JRE implementation issues.

Operating Systems JMeter is a 100% Java application and should run correctly on any system that has a compliant Java implementation. Operating systems tested with JMeter can be view on this page on JMeter wiki. Even if your OS is not listed on the wiki page, JMeter should run on it provided that the JVM is compliant.

2.2. Optional If you plan on doing JMeter development, then you will need one or more optional packages listed below.

Java Compiler If you want to build the JMeter source or develop JMeter plugins, then you will need a fully compliant JDK 6 or higher.

SAX XML Parser JMeter comes with Apache's Xerces XML parser . You have the option of telling JMeter to use a different XML parser. To do so, include the classes for the third-party parser in JMeter's classpath , and update the jmeter.properties file with the full classname of the parser implementation.

www.vskills.in

Page 9

Certified Jmeter Tester Email Support JMeter has extensive Email capabilities. It can send email based on test results, and has a POP3(S)/IMAP(S) sampler. It also has an SMTP(S) sampler.

SSL Encryption To test a web server using SSL encryption (HTTPS), JMeter requires that an implementation of SSL be provided, as is the case with Sun Java 1.4 and above. If your version of Java does not include SSL support, then it is possible to add an external implementation. Include the necessary encryption packages in JMeter's classpath . Also, update system.properties to register the SSL Provider. JMeter HTTP defaults to protocol level TLS. This can be changed by editing the JMeter property https.default.protocol in jmeter.properties or user.properties. The JMeter HTTP samplers are configured to accept all certificates, whether trusted or not, regardless of validity periods, etc. This is to allow the maximum flexibility in testing servers. If the server requires a client certificate, this can be provided. There is also the SSL Manager , for greater control of certificates. The JMeter proxy server (see below) supports recording HTTPS (SSL) The SMTP sampler can optionally use a local trust store or trust all certificates.

JDBC Driver You will need to add your database vendor's JDBC driver to the classpath if you want to do JDBC testing. Make sure the file is a jar file, not a zip.

JMS client JMeter now includes the JMS API from Apache Geronimo, so you just need to add the appropriate JMS Client implementation jar(s) from the JMS provider. Please refer to their documentation for details. There may also be some information on the JMeter Wiki .

Libraries for ActiveMQ JMS At the time of writing, the current version of ActiveMQ is 5.3.2. You will need to add the jar activemq-all-5.3.2.jar to your classpath, e.g. by storing it in the lib/ directory. Alternatively, add the jar activemq-core-5.3.2.jar to the classpath; this requires the javax/management/j2ee classes which can be found in the Apache Geronimo jar geronimo-j2eemanagement_1.0_spec-1.0.jar. The other required jars (such as commons-logging) are already included with JMeter.

2.3. Installation We recommend that most users run the latest release .

www.vskills.in

Page 10

Certified Jmeter Tester To install a release build, simply unzip the zip/tar file into the directory where you want JMeter to be installed. Provided that you have a JRE/JDK correctly installed and the JAVA_HOME environment variable set, there is nothing more for you to do. Note: there can be problems (especially with client-server mode) if the directory path contains any spaces. The installation directory structure should look something like this (where X.Y is version number): apache-jmeter-X.Y apache-jmeter-X.Y/bin apache-jmeter-X.Y/docs apache-jmeter-X.Y/extras apache-jmeter-X.Y/lib/ apache-jmeter-X.Y/lib/ext apache-jmeter-X.Y/lib/junit apache-jmeter-X.Y/licenses apache-jmeter-X.Y/printable_docs You can rename the parent directory (i.e. apache-jmeter-X.Y) if you want, but do not change any of the sub-directory names.

2.4. Running JMeter To run JMeter, run the jmeter.bat (for Windows) or jmeter (for Unix) file. These files are found in the bin directory. After a short time, the JMeter GUI should appear. There are some additional scripts in the bin directory that you may find useful. Windows script files (the .CMD files require Win2K or later): jmeter.bat - run JMeter (in GUI mode by default) jmeter-n.cmd - drop a JMX file on this to run a non-GUI test jmeter-n-r.cmd - drop a JMX file on this to run a non-GUI test remotely jmeter-t.cmd - drop a JMX file on this to load it in GUI mode jmeter-server.bat - start JMeter in server mode mirror-server.cmd - runs the JMeter Mirror Server in non-GUI mode shutdown.cmd - Run the Shutdown client to stop a non-GUI instance gracefully stoptest.cmd - Run the Shutdown client to stop a non-GUI instance abruptly

Note: the special name LAST can be used with jmeter-n.cmd, jmeter-t.cmd and jmeter-n-r.cmd and means the last test plan that was run interactively. The environment variable JVM_ARGS can be used to override JVM settings in the jmeter.bat script. For example: set JVM_ARGS="-Xms1024m -Xmx1024m -Dpropname=propvalue" jmeter -t test.jmx ...

www.vskills.in

Page 11

Certified Jmeter Tester Un*x script files; should work on most Linux/Unix systems: jmeter - run JMeter (in GUI mode by default). Defines some JVM settings which may not work for all JVMs. jmeter-server - start JMeter in server mode (calls jmeter script with appropriate parameters) jmeter.sh - very basic JMeter script with no JVM options specified. mirror-server.sh - runs the JMeter Mirror Server in non-GUI mode shutdown.sh - Run the Shutdown client to stop a non-GUI instance gracefully stoptest.sh - Run the Shutdown client to stop a non-GUI instance abruptly It may be necessary to edit the jmeter shell script if some of the JVM options are not supported by the JVM you are using. The JVM_ARGS environment variable can be used to override or set additional JVM options, for example: JVM_ARGS="-Xms1024m -Xmx1024m" jmeter -t test.jmx [etc.] will override the HEAP settings in the script.

JMeter's Classpath JMeter automatically finds classes from jars in the following directories: JMETER_HOME/lib - used for utility jars JMETER_HOME/lib/ext - used for JMeter components and plugins If you have developed new JMeter components, then you should jar them and copy the jar into JMeter's lib/ext directory. JMeter will automatically find JMeter components in any jars found here. Do not use lib/ext for utility jars or dependency jars used by the plugins; it is only intended for JMeter components and plugins. If you don't want to put JMeter plugin jars in the lib/ext lib/e directory, then define the property search_paths in jmeter.properties. Utility and dependency jars (libraries etc) can be placed in the lib directory. If you don't want to put such jars in the lib directory, then define the property user.classpath or plugin_dependency_paths in jmeter.properties. See below for an explanation of the differences. Other jars (such as JDBC, JMS implementations and any other support libraries needed by the JMeter code) should be placed in the lib directory - not the lib/ext directory, or added to user.classpath .

Note: JMeter will only find .jar files, not .zip. You can also install utility Jar files in $JAVA_HOME/jre/lib/ext, or you can set the property user.classpath in jmeter.properties www.vskills.in

Page 12

Certified Jmeter Tester Note Note that setting the CLASSPATH environment variable will have no effect. This is because JMeter is started with "java -jar", and the java command silently ignores the CLASSPATH variable, and the -classpath/-cp options when -jar is used. [This occurs with all Java programs, not just JMeter.] Using a HTTP(S) Test Script Recorder If you are testing from behind a firewall/proxy server, you may need to provide JMeter with the firewall/proxy server hostname and port number. To do so, run the jmeter[.bat] file from a command line with the following parameters: -H [proxy server hostname or ip address] -P [proxy server port] -N [nonproxy hosts] (e.g. *.apache.org|localhost) -u [username for proxy authentication - if required] -a [password for proxy authentication - if required]

Example : jmeter -H my.proxy.server -P 8000 -u username -a password -N localhost You can also use --proxyHost, --proxyPort, --username, and --password as parameter names Parameters provided on a command-line may be visible to other users on the system. If the proxy host and port are provided, then JMeter sets the following System properties: http.proxyHost http.proxyPort https.proxyHost https.proxyPort If a nonproxy host list is provided, then JMeter sets the following System properties: http.nonProxyHosts https.nonProxyHosts So if you don't wish to set both http and https proxies, you can define the relevant properties in system.properties instead of using the command-line parameters. Proxy Settings can also be defined in a Test Plan, using either the HTTP Request Defaults configuration or the HTTP Request sampler elements. JMeter also has its own in-built Proxy Server, the HTTP(S) Test Script Recorder . This is only used for recording HTTP or HTTPS browser sessions. This is not to be confused with the proxy settings described above, which is used when JMeter makes HTTP or HTTPS requests itself.

www.vskills.in

Page 13

Certified Jmeter Tester NonNon-GUI Mode (Command Line mode) For non-interactive testing, you may choose to run JMeter without the GUI. To do so, use the following command options: -n This specifies JMeter is to run in non-gui mode -t [name of JMX file that contains the Test Plan]. -l [name of JTL file to log sample results to]. -j [name of JMeter run log file]. -r Run the test in the servers specified by the JMeter property "remote_hosts" -R [list of remote servers] Run the test in the specified remote servers The script also lets you specify the optional firewall/proxy server information: -H [proxy server hostname or ip address] -P [proxy server port]

Example : jmeter -n -t my_test.jmx -l log.jtl -H my.proxy.server -P 8000 If the property jmeterengine.stopfail.system.exit is set to true (default is false), then JMeter will invoke System.exit(1) if it cannot stop all threads. Normally this is not necessary.

Server Server Mode For distributed testing , run JMeter in server mode on the remote node(s), and then control the server(s) from the GUI. You can also use non-GUI mode to run remote tests. To start the server(s), run jmeter-server[.bat] on each server host. The script also lets you specify the optional firewall/proxy server information: -H [proxy server hostname or ip address] -P [proxy server port]

Example : jmeter-server -H my.proxy.server -P 8000 If you want the server to exit after a single test has been run, then define the JMeter property server.exitaftertest=true. To run the test from the client in non-GUI mode, use the following command: jmeter -n -t testplan.jmx -r [-Gprop=val] [-Gglobal.properties] [-Z] where: -G is used to define JMeter properties to be set in the servers -X means exit the servers at the end of the test -Rserver1,server2 - can be used instead of -r to provide a list of servers to start Overrides remote_hosts, but does not define the property. If the property jmeterengine.remote.system.exit is set to true (default is false), then JMeter will invoke System.exit(0) after stopping RMI at the end of a test. Normally this is not necessary.

www.vskills.in

Page 14

Certified Jmeter Tester Overriding Properties Via The Command Line Java system properties, JMeter properties, and logging properties can be overridden directly on the command line (instead of modifying jmeter.properties). To do so, use the following options: -D[prop_name]=[value] - defines a java system property value. -J[prop name]=[value] - defines a local JMeter property. -G[prop name]=[value] - defines a JMeter property to be sent to all remote servers. -G[propertyfile] - defines a file containing JMeter properties to be sent to all remote servers. -L[category]=[priority] - overrides a logging setting, setting a particular category to the given priority level. The -L flag can also be used without the category name to set the root logging level.

Examples : jmeter -Duser.dir=/home/mstover/jmeter_stuff \ -Jremote_hosts=127.0.0.1 -Ljmeter.engine=DEBUG jmeter -LDEBUG N.B. The command line properties are processed early in startup, but after the logging system has been set up. Attempts to use the -J flag to update log_level or log_file properties will have no effect.

Logging and error messages JMeter does not generally use pop-up dialog boxes for errors, as these would interfere with running tests. Nor does it report any error for a mis-spelt variable or function; instead the reference is just used as is. See Functions and Variables for more information . If JMeter detects an error during a test, a message will be written to the log file. The log file name is defined in the jmeter.properties file (or using the -j option, see below). It defaults to jmeter.log , and will be found in the directory from which JMeter was launched. The menu Options > Log Viewer displays the log file in a bottom pane on main JMeter window. In the GUI mode, the number of error/fatal messages logged in the log file is displayed at top-right.

Error/fatal counter

The command-line option -j jmeterlogfile allow to process after the initial properties file is read, and before any further properties are processed. It therefore allows the default of jmeter.log to be overridden. The jmeter scripts that take a test plan name as a parameter (e.g. jmeter-n.cmd) have

www.vskills.in

Page 15

Certified Jmeter Tester been updated to define the log file using the test plan name, e.g. for the test plan Test27.jmx the log file is set to Test27.log. When running on Windows, the file may appear as just jmeter unless you have set Windows to show file extensions. [Which you should do anyway, to make it easier to detect viruses and other nasties that pretend to be text files...] As well as recording errors, the jmeter.log file records some information about the test run. For example: 10/17/2003 12:19:20 PM INFO - jmeter.JMeter: Version 1.9.20031002 10/17/2003 12:19:45 PM INFO - jmeter.gui.action.Load: Loading file: c:\mytestfiles\BSH.jmx 10/17/2003 12:19:52 PM INFO - jmeter.engine.StandardJMeterEngine: Running the test! 10/17/2003 12:19:52 PM INFO - jmeter.engine.StandardJMeterEngine: Starting 1 threads for group BSH. Ramp up = 1. 10/17/2003 12:19:52 PM INFO - jmeter.engine.StandardJMeterEngine: Continue on error 10/17/2003 12:19:52 PM INFO - jmeter.threads.JMeterThread: Thread BSH1-1 started 10/17/2003 12:19:52 PM INFO - jmeter.threads.JMeterThread: Thread BSH1-1 is done 10/17/2003 12:19:52 PM INFO - jmeter.engine.StandardJMeterEngine: Test has ended The log file can be helpful in determining the cause of an error, as JMeter does not interrupt a test to display an error dialogue.

Full list of commandcommand-line options Invoking JMeter as "jmeter -?" will print a list of all the command-line options. These are shown below. -h, --help print usage information and exit -v, --version print the version information and exit -p, --propfile {argument} the jmeter property file to use -q, --addprop {argument} additional property file(s) -t, --testfile {argument} the jmeter test(.jmx) file to run -j, --jmeterlogfile {argument} the jmeter log file -l, --logfile {argument} the file to log samples to -n, --nongui run JMeter in nongui mode -s, --server run the JMeter server www.vskills.in

Page 16

Certified Jmeter Tester -H, --proxyHost {argument} Set a proxy server for JMeter to use -P, --proxyPort {argument} Set proxy server port for JMeter to use -u, --username {argument} Set username for proxy server that JMeter is to use -a, --password {argument} Set password for proxy server that JMeter is to use -J, --jmeterproperty {argument}={value} Define additional JMeter properties -G, --globalproperty (argument)[=(value)] Define Global properties (sent to servers) e.g. -Gport=123 or -Gglobal.properties -D, --systemproperty {argument}={value} Define additional System properties -S, --systemPropertyFile {filename} a property file to be added as System properties -L, --loglevel {argument}={value} Define loglevel: [category=]level e.g. jorphan=INFO or jmeter.util=DEBUG -r, --runremote (non-GUI only) Start remote servers (as defined by the jmeter property remote_hosts) -R, --remotestart server1,... (non-GUI only) Start these remote servers (overrides remote_hosts) -d, --homedir {argument} the jmeter home directory to use -X, --remoteexit Exit the remote servers at end of test (non-GUI)

Note: the JMeter log file name is formatted as a SimpleDateFormat (applied to the current date) if it contains paired single-quotes, .e.g. 'jmeter_'yyyyMMddHHmmss'.log' If the special name LAST is used for the -t, -j or -l flags, then JMeter takes that to mean the last test plan that was run in interactive mode.

nonnon-GUI shutdown Prior to version 2.5.1, JMeter invoked System.exit() when a non-GUI test completed. This caused problems for applications that invoke JMeter directly, so JMeter no longer invokes System.exit() for a normal test completion. [Some fatal errors may still invoke System.exit()] JMeter will exit all the non-daemon threads it starts, but it is possible that some non-daemon threads may still remain; these will prevent the JVM from exitting. To detect this situation, JMeter starts a new daemon thread just before it exits. This daemon thread waits a short while; if it returns from the wait, then clearly the JVM has not been able to exit, and the thread prints a message to say why. The property jmeter.exit.check.pause can be used to override the default pause of 2000ms (2secs). If set to 0, then JMeter does not start the daemon thread.

www.vskills.in

Page 17

Certified Jmeter Tester 2.5. Configuring JMeter If you wish to modify the properties with which JMeter runs you need to either modify the jmeter.properties in the /bin directory or create your own copy of the jmeter.properties and specify it in the command line.

Note: You can define additional JMeter properties in the file defined by the JMeter property user.properties which has the default value user.properties . The file will be automatically loaded if it is found in the current directory or if it is found in the JMeter bin directory. Similarly, system.properties is used to update system properties.

Parameters Attribute

Description Required You can specify the class for your SSL implementation if you No ssl.provider don't want to use the built-in Java implementation. You can specify an implementation as your XML parser. The No xml.parser default value is: org.apache.xerces.parsers.SAXParser Comma-delimited list of remote JMeter hosts (or host:port if required). If you are running JMeter in a distributed remote_hosts environment, list the machines where you have JMeter remote No servers running. This will allow you to control those servers from this machine's GUI A list of components you do not want to see in JMeter's menus. As JMeter has more and more components added, you may wish to customize your JMeter to show only those components not_in_menu No you are interested in. 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. List of paths (separated by ;) that JMeter will search for JMeter plugin classes, for example additional samplers. A path item can either be a jar file or a directory. Any jar file in such a No search_paths directory will be automatically included in search_paths, jar files in sub directories are ignored. The given value is in addition to any jars found in the lib/ext directory. List of paths that JMeter will search for utility and plugin dependency classes. Use your platform path separator to separate multiple paths. A path item can either be a jar file or a directory. Any jar file in such a directory will be automatically user.classpath included in user.classpath, jar files in sub directories are No ignored. The given value is in addition to any jars found in the lib directory. All entries will be added to the class path of the system class loader and also to the path of the JMeter internal loader. plugin_dependenc List of paths (separated by ;) that JMeter will search for utility No y_paths and plugin dependency classes. A path item can either be a jar

www.vskills.in

Page 18

Certified Jmeter Tester Attribute

Description Required file or a directory. Any jar file in such a directory will be automatically included in plugin_dependency_paths, jar files in sub directories are ignored. The given value is in addition to any jars found in the lib directory or given by the user.classpath property. All entries will be added to the path of the JMeter internal loader only. For plugin dependencies using plugin_dependency_paths should be preferred over user.classpath. Name of file containing additional JMeter properties. These user.properties are added after the initial property file, but before the -q and -J No options are processed. Name of file containing additional system properties. These are system.properties No added before the -S and -D options are processed.

The command line options and properties files are processed in the following order: -p propfile jmeter.properties (or the file from the -p option) is then loaded -j logfile Logging is initialized user.properties is loaded system.properties is loaded all other command-line options are processed

www.vskills.in

Page 19

Certified Jmeter Tester

3. BUILDING A TEST PLAN A test plan describes a series of steps JMeter will execute when run. A complete test plan will consist of one or more Thread Groups, logic controllers, sample generating controllers, listeners, timers, assertions, and configuration elements.

3.1. Adding and Removing Elements Adding elements to a test plan can be done by right-clicking on an element in the tree, and choosing a new element from the "add" list. Alternatively, elements can be loaded from file and added by choosing the "merge" or "open" option. To remove an element, make sure the element is selected, right-click on the element, and choose the "remove" option.

3.2. Loading and Saving Elements To load an element from file, right click on the existing tree elements to which you want to add the loaded element, and select the "merge" option. Choose the file where your elements are saved. JMeter will merge the elements into the tree. To save tree elements, right click on an element and choose the "Save Selection As ..." option. JMeter will save the element selected, plus all child elements beneath it. In this way, you can save test tree fragments and individual elements for later use. The workbench is not automatically saved with the test plan, but it can be saved separately as above.

3.3. Configuring Tree Elements Any element in the test tree will present controls in JMeter's right-hand frame. These controls allow you to configure the behavior of that particular test element. What can be configured for an element depends on what type of element it is. The Test Tree itself can be manipulated by dragging and dropping components around the test tree.

3.4. Saving the Test Plan Although it is not required, we recommend that you save the Test Plan to a file before running it. To save the Test Plan, select "Save" or "Save Test Plan As ..." from the File menu (with the latest release, it is no longer necessary to select the Test Plan element first). JMeter allows you to save the entire Test Plan tree or only a portion of it. To save only the elements located in a particular "branch" of the Test Plan tree, select the Test Plan element in the tree from which to start the "branch", and then click your right mouse button to access the "Save Selection As ..." menu item. Alternatively, select the appropriate Test Plan element and then select "Save Selection As ..." from the Edit menu.

www.vskills.in

Page 20

Certified Jmeter Tester 3.5. Running a Test Plan To run your test plan, choose "Start" (Control + r) from the "Run" menu item. When JMeter is running, it shows a small green box at the right hand end of the section just under the menu bar. You can also check the "Run" menu. If "Start" is disabled, and "Stop" is enabled, then JMeter is running your test plan (or, at least, it thinks it is). The numbers to the left of the green box are the number of active threads / total number of threads. These only apply to a locally run test; they do not include any threads started on remote systems when using client-server mode.

Stopping a Test There are two types of stop command available from the menu: Stop (Control + '.') - stops the threads immediately if possible. In Versions of JMeter after 2.3.2, many samplers are now Interruptible which means that active samples can be terminated early. The stop command will check that all threads have stopped within the default timeout, which is 5000 ms = 5 seconds. [This can be changed using the JMeter propertyjmeterengine.threadstop.wait ] If the threads have not stopped, then a message is displayed. The Stop command can be retried, but if it fails, then it is necessary to exit JMeter to clean up. Shutdown (Control + ',')- requests the threads to stop at the end of any current work. Will not interrupt any active samples. The modal shutdown dialog box will remain active until all threads have stopped. Versions of JMeter after 2.3.2 allow a Stop to be initiated if Shutdown is taking too long. Close the Shutdown dialog box and select Run/Stop, or just press Control + '.'. When running JMeter in non-GUI mode, there is no Menu, and JMeter does not react to keystrokes such as Control + '.'. So in versions after 2.3.2, JMeter non-GUI mode will listen for commands on a specific port (default 4445, see the JMeter property jmeterengine.nongui.port ). In versions after 2.4, JMeter supports automatic choice of an alternate port if the default port is being used (for example by another JMeter instance). In this case, JMeter will try the next higher port, continuing until it reaches the JMeter property jmeterengine.nongui.maxport) which defaults to 4455. If maxport is less than or equal to port , port scanning will not take place. Note that JMeter 2.4 and earlier did not set up the listener for non-GUI clients, only non-GUI standalone tests; this has been fixed. The chosen port is displayed in the console window. The commands currently supported are: Shutdown - graceful shutdown StopTestNow - immediate shutdown

www.vskills.in

Page 21

Certified Jmeter Tester These commands can be sent by using the shutdown[.cmd|.sh] orstoptest[.cmd|.sh] script respectively. The scripts are to be found in the JMeter bin directory. The commands will only be accepted if the script is run from the same host.

3.6. Error reporting reporting JMeter reports warnings and errors to the jmeter.log file, as well as some information on the test run itself. JMeter shows at the right hand end of its window, the number of warnings/errors found in jmeter.log file next to the warning icon. Click on the warning icon to show the jmeter.log file at the bottom of JMeter's window. Just occasionally there may be some errors that JMeter is unable to trap and log; these will appear on the command console. If a test is not behaving as you expect, please check the log file in case any errors have been reported (e.g. perhaps a syntax error in a function call). Sampling errors (e.g. HTTP 404 - file not found) are not normally reported in the log file. Instead these are stored as attributes of the sample result. The status of a sample result can be seen in the various different Listeners.

www.vskills.in

Page 22

Certified Jmeter Tester

4. ELEMENTS OF A TEST PLAN PLAN The Test Plan object has a checkbox called "Functional Testing". If selected, it will cause JMeter to record the data returned from the server for each sample. If you have selected a file in your test listeners, this data will be written to file. This can be useful if you are doing a small run to ensure that JMeter is configured correctly, and that your server is returning the expected results. The consequence is that the file will grow huge quickly, and JMeter's performance will suffer. This option should be off if you are doing stress-testing (it is off by default). If you are not recording the data to file, this option makes no difference. You can also use the Configuration button on a listener to decide what fields to save.

4.1. ThreadGroup Thread group elements are the beginning points of any test plan. All controllers and samplers must be under a thread group. Other elements, e.g. Listeners, may be placed directly under the test plan, in which case they will apply to all the thread groups. As the name implies, the thread group element controls the number of threads JMeter will use to execute your test. The controls for a thread group allow you to: Set the number of threads Set the ramp-up period Set the number of times to execute the test Each thread will execute the test plan in its entirety and completely independently of other test threads. Multiple threads are used to simulate concurrent connections to your server application. The ramp-up period tells JMeter how long to take to "ramp-up" to the full number of threads chosen. If 10 threads are used, and the ramp-up period is 100 seconds, then JMeter will take 100 seconds to get all 10 threads up and running. Each thread will start 10 (100/10) seconds after the previous thread was begun. If there are 30 threads and a ramp-up period of 120 seconds, then each successive thread will be delayed by 4 seconds. Ramp-up needs to be long enough to avoid too large a work-load at the start of a test, and short enough that the last threads start running before the first ones finish (unless one wants that to happen). Start with Ramp-up = number of threads and adjust up or down as needed. By default, the thread group is configured to loop once through its elements. Version 1.9 introduces a test run scheduler . Click the checkbox at the bottom of the Thread Group panel to reveal extra fields in which you can enter the start and end times of the run. When the test is started, JMeter will wait if necessary until the start-time has been reached. At the end of each cycle, JMeter checks if the end-time has been reached, and if so, the run is stopped, otherwise the test is allowed to continue until the iteration limit is reached.

www.vskills.in

Page 23

Certified Jmeter Tester Alternatively, one can use the relative delay and duration fields. Note that delay overrides starttime, and duration over-rides end-time.

4.2. Controllers JMeter has two types of Controllers: Samplers and Logical Controllers. These drive the processing of a test. Samplers tell JMeter to send requests to a server. For example, add an HTTP Request Sampler if you want JMeter to send an HTTP request. You can also customize a request by adding one or more Configuration Elements to a Sampler. For more information, see Samplers . Logical Controllers let you customize the logic that JMeter uses to decide when to send requests. For example, you can add an Interleave Logic Controller to alternate between two HTTP Request Samplers. For more information, see Logical Controllers .

Samplers Samplers tell JMeter to send requests to a server and wait for a response. They are processed in the order they appear in the tree. Controllers can be used to modify the number of repetitions of a sampler. JMeter samplers include: FTP Request HTTP Request JDBC Request Java object request LDAP Request SOAP/XML-RPC Request WebService (SOAP) Request Each sampler has several properties you can set. You can further customize a sampler by adding one or more Configuration Elements to the Test Plan. If you are going to send multiple requests of the same type (for example, HTTP Request) to the same server, consider using a Defaults Configuration Element. Each controller has one or more Defaults elements (see below). Remember to add a Listener to your test plan to view and/or store the results of your requests to disk. If you are interested in having JMeter perform basic validation on the response of your request, add an Assertion to the sampler. For example, in stress testing a web application, the server may return a successful "HTTP Response" code, but the page may have errors on it or may be missing sections. You could add assertions to check for certain HTML tags, common error strings, and so on. JMeter lets you create these assertions using regular expressions.

www.vskills.in

Page 24

Certified Jmeter Tester Logic Controllers Logic Controllers let you customize the logic that JMeter uses to decide when to send requests. Logic Controllers can change the order of requests coming from their child elements. They can modify the requests themselves, cause JMeter to repeat requests, etc. To understand the effect of Logic Controllers on a test plan, consider the following test tree: Test Plan Thread Group Once Only Controller Login Request (an HTTP Request ) Load Search Page (HTTP Sampler) Interleave Controller Search "A" (HTTP Sampler) Search "B" (HTTP Sampler) HTTP default request (Configuration Element) HTTP default request (Configuration Element) Cookie Manager (Configuration Element) The first thing about this test is that the login request will be executed only the first time through. Subsequent iterations will skip it. This is due to the effects of the Once Only Controller . After the login, the next Sampler loads the search page (imagine a web application where the user logs in, and then goes to a search page to do a search). This is just a simple request, not filtered through any Logic Controller. After loading the search page, we want to do a search. Actually, we want to do two different searches. However, we want to re-load the search page itself between each search. We could do this by having 4 simple HTTP request elements (load search, search "A", load search, search "B"). Instead, we use the Interleave Controller which passes on one child request each time through the test. It keeps the ordering (ie - it doesn't pass one on at random, but "remembers" its place) of its child elements. Interleaving 2 child requests may be overkill, but there could easily have been 8, or 20 child requests. Note the HTTP Request Defaults that belongs to the Interleave Controller. Imagine that "Search A" and "Search B" share the same PATH info (an HTTP request specification includes domain, port, method, protocol, path, and arguments, plus other optional items). This makes sense - both are search requests, hitting the same back-end search engine (a servlet or cgi-script, let's say). Rather than configure both HTTP Samplers with the same information in their PATH field, we can abstract that information out to a single Configuration Element. When the Interleave Controller "passes on" requests from "Search A" or "Search B", it will fill in the blanks with values from the HTTP default request Configuration Element. So, we leave the PATH field blank for those requests, and put that information into the Configuration Element. In this case, this is a minor benefit at best, but it demonstrates the feature. The next element in the tree is another HTTP default request, this time added to the Thread Group itself. The Thread Group has a built-in Logic Controller, and thus, it uses this

www.vskills.in

Page 25

Certified Jmeter Tester Configuration Element exactly as described above. It fills in the blanks of any Request that passes through. It is extremely useful in web testing to leave the DOMAIN field blank in all your HTTP Sampler elements, and instead, put that information into an HTTP default request element, added to the Thread Group. By doing so, you can test your application on a different server simply by changing one field in your Test Plan. Otherwise, you'd have to edit each and every Sampler. The last element is a HTTP Cookie Manager . A Cookie Manager should be added to all web tests - otherwise JMeter will ignore cookies. By adding it at the Thread Group level, we ensure that all HTTP requests will share the same cookies. Logic Controllers can be combined to achieve various results. See the list of built-in Logic Controllers .

Test Fragments The Test Fragment element is a special type of controller that exists on the Test Plan tree at the same level as the Thread Group element. It is distinguished from a Thread Group in that it is not executed unless it is referenced by either a Module Controlleror an Include_Controller . This element is purely for code re-use within Test Plans and was introduced in Version 2.5

4.3. Listeners Listeners provide access to the information JMeter gathers about the test cases while JMeter runs. The Graph Results listener plots the response times on a graph. The "View Results Tree" Listener shows details of sampler requests and responses, and can display basic HTML and XML representations of the response. Other listeners provide summary or aggregation information. Additionally, listeners can direct the data to a file for later use. Every listener in JMeter provides a field to indicate the file to store data to. There is also a Configuration button which can be used to choose which fields to save, and whether to use CSV or XML format. Note that all Listeners save the same data; the only difference is in the way the data is presented on the screen. Listeners can be added anywhere in the test, including directly under the test plan. They will collect data only from elements at or below their level. There are several listeners that come with JMeter.

4.4. Timers By default, a JMeter thread sends requests without pausing between each request. We recommend that you specify a delay by adding one of the available timers to your Thread Group. If you do not add a delay, JMeter could overwhelm your server by making too many requests in a very short amount of time. The timer will cause JMeter to delay a certain amount of time before each sampler which is in its scope . If you choose to add more than one timer to a Thread Group, JMeter takes the sum of the timers and pauses for that amount of time before executing the samplers to which the timers apply.

www.vskills.in

Page 26

Certified Jmeter Tester Timers can be added as children of samplers or controllers in order to restrict the samplers to which they are applied. To provide a pause at a single place in a test plan, one can use the Test ActionSampler.

4.5. Assertions Assertions allow you to assert facts about responses received from the server being tested. Using an assertion, you can essentially "test" that your application is returning the results you expect it to. For instance, you can assert that the response to a query will contain some particular text. The text you specify can be a Perl-style regular expression, and you can indicate that the response is to contain the text, or that it should match the whole response. You can add an assertion to any Sampler. For example, you can add an assertion to a HTTP Request that checks for the text, "". JMeter will then check that the text is present in the HTTP response. If JMeter cannot find the text, then it will mark this as a failed request. Note that assertions apply to all samplers which are in its scope . To restrict the assertion to a single sampler, add the assertion as a child of the sampler. To view the assertion results, add an Assertion Listener to the Thread Group. Failed Assertions will also show up in the Tree View and Table Listeners, and will count towards the error %age for example in the Aggregate and Summary reports.

4.6. Configuration Elements A configuration element works closely with a Sampler. Although it does not send requests (except for HTTP(S) Test Script Recorder ), it can add to or modify requests. A configuration element is accessible from only inside the tree branch where you place the element. For example, if you place an HTTP Cookie Manager inside a Simple Logic Controller, the Cookie Manager will only be accessible to HTTP Request Controllers you place inside the Simple Logic Controller (see figure 1). The Cookie Manager is accessible to the HTTP requests "Web Page 1" and "Web Page 2", but not "Web Page 3". Also, a configuration element inside a tree branch has higher precedence than the same element in a "parent" branch. For example, we defined two HTTP Request Defaults elements, "Web Defaults 1" and "Web Defaults 2". Since we placed "Web Defaults 1" inside a Loop Controller, only "Web Page 2" can access it. The other HTTP requests will use "Web Defaults 2", since we placed it in the Thread Group (the "parent" of all other branches).

www.vskills.in

Page 27

Certified Jmeter Tester

Figure 1 - Test Plan Showing Accessability of Configuration Elements

The User Defined VariablesConfiguration element is different. It is processed at the start of a test, no matter where it is placed. For simplicity, it is suggested that the element is placed only at the start of a Thread Group.

4.7. PrePre-Processor Elements A Pre-Processor executes some action prior to a Sampler Request being made. If a Pre-Processor is attached to a Sampler element, then it will execute just prior to that sampler element running. A Pre-Processor is most often used to modify the settings of a Sample Request just before it runs, or to update variables that aren't extracted from response text. See the scoping rules for more details on when Pre-Processors are executed.

4.8. PostPost-Processor Elements A Post-Processor executes some action after a Sampler Request has been made. If a PostProcessor is attached to a Sampler element, then it will execute just after that sampler element runs. A Post-Processor is most often used to process the response data, often to extract values from it. See the scoping rules for more details on when Post-Processors are executed.

4.9. Execution order Configuration elements Pre-Processors Timers Sampler Post-Processors (unless SampleResult is null) Assertions (unless SampleResult is null) Listeners (unless SampleResult is null) Please note that Timers, Assertions, Pre- and Post-Processors are only processed if there is a sampler to which they apply. Logic Controllers and Samplers are processed in the order in which they appear in the tree. Other test elements are processed according to the scope

www.vskills.in

Page 28

Certified Jmeter Tester in which they are found, and the type of test element. [Within a type, elements are processed in the order in which they appear in the tree]. For example, in the following test plan: Controller Post-Processor 1 Sampler 1 Sampler 2 Timer 1 Assertion 1 Pre-Processor 1 Timer 2 Post-Processor 2 The order of execution would be: Pre-Processor 1 Timer 1 Timer 2 Sampler 1 Post-Processor 1 Post-Processor 2 Assertion 1 Pre-Processor 1 Timer 1 Timer 2 Sampler 2 Post-Processor 1 Post-Processor 2 Assertion 1

4.10. Scoping Rules The JMeter test tree contains elements that are both hierarchical and ordered. Some elements in the test trees are strictly hierarchical (Listeners, Config Elements, Post-Procesors, Pre-Processors, Assertions, Timers), and some are primarily ordered (controllers, samplers). When you create your test plan, you will create an ordered list of sample request (via Samplers) that represent a set of steps to be executed. These requests are often organized within controllers that are also ordered. Given the following test tree:

www.vskills.in

Page 29

Certified Jmeter Tester

Example test tree

The order of requests will be, One, Two, Three, Four. Some controllers affect the order of their subelements, and you can read about these specific controllers in the component reference . Other elements are hierarchical. An Assertion, for instance, is hierarchical in the test tree. If its parent is a request, then it is applied to that request. If its parent is a Controller, then it affects all requests that are descendants of that Controller. In the following test tree:

Hierarchy example

Assertion #1 is applied only to Request One, while Assertion #2 is applied to Requests Two and Three. Another example, this time using Timers:

complex example

In this example, the requests are named to reflect the order in which they will be executed. Timer #1 will apply to Requests Two, Three, and Four (notice how order is irrelevant for hierarchical elements). Assertion #1 will apply only to Request Three. Timer #2 will affect all the requests. www.vskills.in

Page 30

Certified Jmeter Tester

Hopefully these examples make it clear how configuration (hierarchical) elements are applied. If you imagine each Request being passed up the tree branches, to its parent, then to its parent's parent, etc, and each time collecting all the configuration elements of that parent, then you will see how it works. The Configuration elements Header Manager, Cookie Manager and Authorization manager are treated differently from the Configuration Default elements. The settings from the Configuration Default elements are merged into a set of values that the Sampler Sampler has access to. However, the settings from the Managers are not merged. If more than one Manager is in the scope of a Sampler, only one Manager is used, but there is currently no way to specify which is used.

4.11. Properties and Variables JMeter properties are defined in jmeter.properties (see Gettting Started - Configuring JMeter for more details). Properties are global to jmeter, and are mostly used to define some of the defaults JMeter uses. For example the property remote_hosts defines the servers that JMeter will try to run remotely. Properties can be referenced in test plans - seeFunctions - read a property - but cannot be used for thread-specific values. JMeter variables are local to each thread. The values may be the same for each thread, or they may be different. If a variable is updated by a thread, only the thread copy of the variable is changed. For example the Regular Expression Extractor Post-Processor will set its variables according to the sample that its thread has read, and these can be used later by the same thread. For details of how to reference variables and functions, see Functions and Variables Note that the values defined by the Test Plan and the User Defined Variablesconfiguration element are made available to the whole test plan at startup. If the same variable is defined by multiple UDV elements, then the last one takes effect. Once a thread has started, the initial set of variables is copied to each thread. Other elements such as the User Parameters Pre-Processor or Regular Expression Extractor Post-Processor may be used to redefine the same variables (or create new ones). These redefinitions only apply to the current thread. The setProperty function can be used to define a JMeter property. These are global to the test plan, so can be used to pass information between threads - should that be needed. Both variables and properties are case-sensitive.

4.12. Using Variables to parameterise tests Variables don't have to vary - they can be defined once, and if left alone, will not change value. So you can use them as short-hand for expressions that appear frequently in a test plan. Or for items which are constant during a run, but which may vary between runs. For example, the name of a host, or the number of threads in a thread group.

www.vskills.in

Page 31

Certified Jmeter Tester When deciding how to structure a Test Plan, make a note of which items are constant for the run, but which may change between runs. Decide on some variable names for these - perhaps use a naming convention such as prefixing them with C_ or K_ or using uppercase only to distinguish them from variables that need to change during the test. Also consider which items need to be local to a thread - for example counters or values extracted with the Regular Expression PostProcessor. You may wish to use a different naming convention for these. For example, you might define the following on the Test Plan: HOST THREADS LOOPS

www.example.com 10 20

You can refer to these in the test plan as ${HOST} ${THREADS} etc. If you later want to change the host, just change the value of the HOST variable. This works fine for small numbers of tests, but becomes tedious when testing lots of different combinations. One solution is to use a property to define the value of the variables, for example: HOST THREADS LOOPS

${__P(host,www.example.com)} ${__P(threads,10)} ${__P(loops,20)}

You can then change some or all of the values on the command-line as follows: jmeter ... -Jhost=www3.example.org -Jloops=13

www.vskills.in

Page 32

Certified Jmeter Tester

5. BUILDING A WEB TEST PLAN PLAN In this section, you will learn how to create a basic Test Plan to test a Web site. You will create five users that send requests to two pages on the JMeter Web site. Also, you will tell the users to run their tests twice. So, the total number of requests is (5 users) x (2 requests) x (repeat 2 times) = 20 HTTP requests. To construct the Test Plan, you will use the following elements:Thread Group , HTTP Request , HTTP Request Defaults , and Graph Results . For a more advanced Test Plan, see Building an Advanced Web Test Plan .

5.1. Adding Users The first step you want to do with every JMeter Test Plan is to add a Thread Group element. The Thread Group tells JMeter the number of users you want to simulate, how often the users should send requests, and the how many requests they should send. Go ahead and add the ThreadGroup element by first selecting the Test Plan, clicking your right mouse button to get the Add menu, and then select Add --> ThreadGroup. You should now see the Thread Group element under Test Plan. If you do not see the element, then "expand" the Test Plan tree by clicking on the Test Plan element. Next, you need to modify the default properties. Select the Thread Group element in the tree, if you have not already selected it. You should now see the Thread Group Control Panel in the right section of the JMeter window (see Figure 5.1 below)

Figure 5.1. Thread Group with Default Values

Start by providing a more descriptive name for our Thread Group. In the name field, enter JMeter Users. Next, increase the number of users (called threads) to 5. In the next field, the Ramp-Up Period, leave the default value of 1 seconds. This property tells JMeter how long to delay between starting each user. For example, if you enter a Ramp-Up Period of 5 seconds, JMeter will finish starting all of your users by the end of the 5 seconds. So, if we have 5 users and a 5 second Ramp-Up Period, then the delay between starting users would be 1 second

www.vskills.in

Page 33

Certified Jmeter Tester (5 users / 5 seconds = 1 user per second). If you set the value to 0, then JMeter will immediately start all of your users. Finally enter a value of 2 in the Loop Count field. This property tells JMeter how many times to repeat your test. If you enter a loop count value of 1, then JMeter will run your test only once. To have JMeter repeatedly run your Test Plan, select the Forever checkbox. In most applications, you have to manually accept changes you make in a Control Panel. However, in JMeter, the Control Panel automatically accepts your changes as you make them. If you change the name of an element, the tree will be updated with the new text after you leave the Control Panel (for example, when selecting another tree element).

Figure 5.2. JMeter Users Thread Group

5.2. Adding Default HTTP Request Properties Properties Now that we have defined our users, it is time to define the tasks that they will be performing. In this section, you will specify the default settings for your HTTP requests. And then, in section 5.3, you will add HTTP Request elements which use some of the default settings you specified here. Begin by selecting the JMeter Users (Thread Group) element. Click your right mouse button to get the Add menu, and then select Add --> Config Element --> HTTP Request Defaults. Then, select this new element to view its Control Panel (see Figure 5.3).

www.vskills.in

Page 34

Certified Jmeter Tester

Figure 5.3. HTTP Request Defaults

Like most JMeter elements, the HTTP Request Defaults Control Panel has a name field that you can modify. In this example, leave this field with the default value. Skip to the next field, which is the Web Server's Server Name/IP. For the Test Plan that you are building, all HTTP requests will be sent to the same Web server, jmeter.apache.org. Enter this domain name into the field. This is the only field that we will specify a default, so leave the remaining fields with their default values. The HTTP Request Defaults element does not tell JMeter to send an HTTP request. It simply defines the default values that the HTTP Request elements use. See Figure 5.4 for the completed HTTP Request Defaults element

Figure 5.4. HTTP Defaults for our Test Plan

www.vskills.in

Page 35

Certified Jmeter Tester 5.3. Adding Cookie Support Nearly all web testing should use cookie support, unless your application specifically doesn't use cookies. To add cookie support, simply add an HTTP Cookie Manager to each Thread Group in your test plan. This will ensure that each thread gets its own cookies, but shared across all HTTP Request objects. To add the HTTP Cookie Manager , simply select the Thread Group , and choose Add --> Config Element --> HTTP Cookie Manager, either from the Edit Menu, or from the right-click pop-up menu.

5.4. Adding HTTP Requests In our Test Plan, we need to make two HTTP requests. The first one is for the JMeter home page (http://jmeter.apache.org/), and the second one is for the Changes page (http://jmeter.apache.org/changes.html). JMeter sends requests in the order that they appear in the tree. Start by adding the first HTTP Request to the JMeter Users element (Add --> Sampler --> HTTP Request). Then, select the HTTP Request element in the tree and edit the following properties (see Figure 5.5): Change the Name field to "Home Page". Set the Path field to "/". Remember that you do not have to set the Server Name field because you already specified this value in the HTTP Request Defaults element.

Figure 5.5. HTTP Request for JMeter Home Page

www.vskills.in

Page 36

Certified Jmeter Tester Next, add the second HTTP Request and edit the following properties (see Figure 5.6: Change the Name field to "Changes". Set the Path field to "/changes.html".

Figure 5.6. HTTP Request for JMeter Changes Page

5.5. Adding a Listener to View Store the Test Results The final element you need to add to your Test Plan is a Listener . This element is responsible for storing all of the results of your HTTP requests in a file and presenting a visual model of the data. Select the JMeter Users element and add a Graph Results listener (Add --> Listener --> Graph Results). Next, you need to specify a directory and filename of the output file. You can either type it into the filename field, or select the Browse button and browse to a directory and then enter a filename.

www.vskills.in

Page 37

Certified Jmeter Tester

Figure 5.7. Graph Results Listener

5.6. Logging in to a webweb-site It's not the case here, but some web-sites require you to login before permitting you to perform certain actions. In a web-browser, the login will be shown as a form for the user name and password, and a button to submit the form. The button generates a POST request, passing the values of the form items as parameters. To do this in JMeter, add an HTTP Request, and set the method to POST. You'll need to know the names of the fields used by the form, and the target page. These can be found out by inspecting the code of the login page. [If this is difficult to do, you can use the JMeter Proxy Recorder to record the login sequence.] Set the path to the target of the submit button. Click the Add button twice and enter the username and password details. Sometimes the login form contains additional hidden fields. These will need to be added as well.

www.vskills.in

Page 38

Certified Jmeter Tester

Figure 5.8. Sample HTTP login request

www.vskills.in

Page 39

Certified Jmeter Tester

6. BUILDING AN ADVANCED WEB TEST PLAN In this section, you will learn how to create advanced Test Plans to test a Web site. For an example of a basic Test Plan, see Building a Web Test Plan .

6.1. Handling User Sessions With URL Rewriting If your web application uses URL rewriting rather than cookies to save session information, then you'll need to do a bit of extra work to test your site. To respond correctly to URL rewriting, JMeter needs to parse the HTML received from the server and retrieve the unique session ID. Use the appropriate HTTP URL Re-writing Modifier to accomplish this. Simply enter the name of your session ID parameter into the modifier, and it will find it and add it to each request. If the request already has a value, it will be replaced. If "Cache Session Id?" is checked, then the last found session id will be saved, and will be used if the previous HTTP sample does not contain a session id. URL Rewriting Example Download this example . In Figure 1 is shown a test plan using URL rewriting. Note that the URL Re-writing modifier is added to the SimpleController, thus assuring that it will only affect requests under that SimpleController.

Figure 1 - Test Tree

In Figure 2, we see the URL Re-writing modifier GUI, which just has a field for the user to specify the name of the session ID parameter. There is also a checkbox for indicating that the session ID should be part of the path (separated by a ";"), rather than a request parameter

Figure 2 - Request parameters

6.2. Using a Header Manager The HTTP Header Manager lets you customize what information JMeter sends in the HTTP request header. This header includes properties like "User-Agent", "Pragma", "Referer", etc.

www.vskills.in

Page 40

Certified Jmeter Tester

The HTTP Header Manager , like the HTTP Cookie Manager , should probably be added at the Thread Group level, unless for some reason you wish to specify different headers for the differentHTTP Request objects in your test.

www.vskills.in

Page 41

Certified Jmeter Tester

7. BUILDING A DATABASE DATABASE TEST PLAN In this section, you will learn how to create a basic Test Plan to test a database server. You will create fifty users that send 2 SQL requests to the database server. Also, you will tell the users to run their tests 100 times. So, the total number of requests is (50 users) x (2 requests) x (repeat 100 times) = 10'000 JDBC requests. To construct the Test Plan, you will use the following elements: Thread Group , JDBC Request , Summary Report . This example uses the MySQL database driver. To use this driver, its containing .jar file (ex. mysql-connector-java-X.X.X-bin.jar) must be copied to the JMeter ./lib directory (see JMeter's Classpath for more details).

7.1. Adding Users The first step you want to do with every JMeter Test Plan is to add a Thread Group element. The Thread Group tells JMeter the number of users you want to simulate, how often the users should send requests, and the how many requests they should send. Go ahead and add the ThreadGroup element by first selecting the Test Plan, clicking your right mouse button to get the Add menu, and then select Add --> ThreadGroup . You should now see the Thread Group element under Test Plan. If you do not see the element, then "expand" the Test Plan tree by clicking on the Test Plan element. Next, you need to modify the default properties. Select the Thread Group element in the tree, if you have not already selected it. You should now see the Thread Group Control Panel in the right section of the JMeter window (see Figure 7.1 below)

Figure 7.1. Thread Group with Default Values

Start by providing a more descriptive name for our Thread Group. In the name field, enter JDBC Users. You will need a valid database, database table, and user-level access to that table. In the example shown here, the database is 'cloud' and the table name is 'vm_instance'.

www.vskills.in

Page 42

Certified Jmeter Tester Next, increase the number of users to 50. In the next field, the Ramp-Up Period, leave the value of 10 seconds. This property tells JMeter how long to delay between starting each user. For example, if you enter a Ramp-Up Period of 10 seconds, JMeter will finish starting all of your users by the end of the 10 seconds. So, if we have 50 users and a 10 second Ramp-Up Period, then the delay between starting users would be 200 milliseconds (10 seconds / 50 users = 0.2 user per second). If you set the value to 0, then JMeter will immediately start all of your users. Finally, enter a value of 100 in the Loop Count field. This property tells JMeter how many times to repeat your test. To have JMeter repeatedly run your Test Plan, select the Forever checkbox. In most applications, you have to manually accept changes you make in a Control Panel. However, in JMeter, the Control Panel automatically accepts your changes as you make them. If you change the name of an element, the tree will be updated with the new text after you leave the Control Panel (for example, when selecting another tree element). See Figure 7.2 for the completed JDBC Users Thread Group.

Figure 7.2. JDBC Users Thread Group

7.2. Adding JDBC Requests Requests Now that we have defined our users, it is time to define the tasks that they will be performing. In this section, you will specify the JDBC requests to perform. Begin by selecting the JDBC Users element. Click your right mouse button to get the w Add menu, and then select Add --> Config Element --> JDBC Connection Configuration . Then, select this new element to view its Control Panel (see Figure 7.3). Set up the following fields (these assume we will be using a MySQL database called 'cloud'): Variable name (here: myDatabase) bound to pool. This needs to uniquely identify the configuration. It is used by the JDBC Sampler to identify the configuration to be used. Database URL: jdbc:mysql://ipOfTheServer:3306/cloud JDBC Driver class: com.mysql.jdbc.Driver Username: the username of database

www.vskills.in

Page 43

Certified Jmeter Tester Password: password for the username The other fields on the screen can be left as the defaults. JMeter creates a database connection pool with the configuration settings as specified in the Control Panel. The pool is referred to in JDBC Requests in the 'Variable Name' field. Several different JDBC Configuration elements can be used, but they must have unique names. Every JDBC Request must refer to a JDBC Configuration pool. More than one JDBC Request can refer to the same pool.

Figure 7.3. JDBC Configuration

Selecting the JDBC Users element again. Click your right mouse button to get the Add menu, and then select Add --> Sampler --> JDBC Request . Then, select this new element to view its Control Panel (see Figure 7.4).

Figure 7.4. JDBC Request

www.vskills.in

Page 44

Certified Jmeter Tester In our Test Plan, we will make two JDBC requests. The first one is for select all 'Running' VM instances, and the second is to select 'Expunging' VM instance (obviously you should change these to examples appropriate for your particular database). These are illustrated below. JMeter sends requests in the order that you add them to the tree. Change the Name to 'VM Running'. Enter the Pool Name: 'myDatabase' (same as in the configuration element) Enter the SQL Query String field. Enter the Parameter values field with 'Running' value. Enter the Parameter types with 'VARCHAR'.

Figure 7.5. JDBC Request for the first SQL request

Next, add the second JDBC Request and edit the following properties (see Figure 7.6): Change the Name to 'VM Expunging'. Change the value of Parameter values to 'Expunging'.

www.vskills.in

Page 45

Certified Jmeter Tester

Figure 7.6. JDBC Request for the second request

7.3. Adding a Listener to View/Store the Test Results The final element you need to add to your Test Plan is a Listener . This element is responsible for storing all of the results of your JDBC requests in a file and presenting the results. Select the JDBC Users element and add a Summary Report listener ( Add --> --> Listener --> --> Summary Report ). Save the test plan, and run the test with the menu Run --> Start or Ctrl+R The listener shows the results.

Figure 7.7. Graph results Listener

www.vskills.in

Page 46

Certified Jmeter Tester

8. BUILDING AN FTP TEST PLAN In this section, you will learn how to create a basic Test Plan to test an FTP site. You will create four users that send requests for two files on a FTP site. Also, you will tell the users to run their tests twice. So, the total number of requests is (4 users) x (2 requests) x (repeat 2 times) = 16 FTP requests. To construct the Test Plan, you will use the following elements: Thread Group , FTP Request , FTP Request Defaults , and View Results in Table .

8.1. Adding Users The first step you want to do with every JMeter Test Plan is to add a Thread Group element. The Thread Group tells JMeter the number of users you want to simulate, how often the users should send requests, and the how many requests they should send. Go ahead and add the Thread Group element by first selecting the Test Plan, clicking your right mouse button to get the Add menu, and then select Add --> --> ThreadGroup. ThreadGroup You should now see the Thread Group element under Test Plan. Plan If you do not see the element, then "expand" the Test Plan tree by clicking on the Test Plan element. Next, you need to modify the default properties. Select the Thread Group element in the tree, if you have not already selected it. You should now see the Thread Group Control Panel in the right section of the JMeter window (see Figure 8.1 below)

Figure 8.1. Thread Group with Default Values

Start by providing a more descriptive name for our Thread Thread Group. Group In the name field, enter 'FTP Users'. Next, increase the number of users to 4.

www.vskills.in

Page 47

Certified Jmeter Tester In the next field, the Ramp-Up Period, leave the default value of 0 seconds. This property tells JMeter how long to delay between starting each user. For example, if you enter a Ramp-UpPeriod of 5 seconds, JMeter will finish starting all of your users by the end of the 5 seconds. So, if we have 5 users and a 5 second Ramp-Up Period, then the delay between starting users would be 1 second (5 users / 5 seconds = 1 user per second). If you set the value to 0, then JMeter will immediately start all of your users. Finally, enter a value of 2 in the Loop Count field. This property tells JMeter how many times to repeat your test. To have JMeter repeatedly run your Test Plan, select the Forever checkbox. In most applications, you have to manually accept changes you make in a Control Panel. However, in JMeter, the Control Panel automatically accepts your changes as you make them. If you change the name of an element, the tree will be updated with the new text after you leave the Control Panel (for example, when selecting another tree element). See Figure 8.2 for the completed FTP Users Thread Group.

Figure 8.2. FTP Users Thread Group

8.2. Adding Default FTP Request Properties Now that we have defined our users, it is time define the tasks that they will be performing. In this section, you will specify the default settings for your FTP requests. And then, in section 8.3, you will add FTP Request elements which use some of the default settings you specified here. Begin by selecting the FTP Users element. Click your right mouse button to get the Add menu, and then select Add --> Config Element --> FTP Request Defaults. Then, select this new element to view its Control Panel (see Figure 8.3).

www.vskills.in

Page 48

Certified Jmeter Tester

Figure 8.3. FTP Request Defaults

Like most JMeter elements, the FTP Request Defaults Control Panel has a name field that you can modify. In this example, leave this field with the default value. Skip to the next field, which is the FTP Server's Server Name/IP. For the Test Plan that you are building, all FTP requests will be sent to the same FTP server, ftp.domain.com in this case. Enter this domain name into the field. This is the only field that we will specify a default, so leave the remaining fields with their default values. The FTP Request Defaults element does not tell JMeter to send an FTP request. It simply defines the default values that the FTP Request elements use.

Figure 8.4. FTP Defaults for our Test Plan

8.3. Adding FTP Requests In our Test Plan , we need to make two FTP requests . JMeter sends requests in the order that they appear in the tree. Start by adding the first FTP Request to the FTP Users element ( Add --> Sampler Sample --> FTP Request ). Then, select the FTP Request element in the tree and edit the following properties (see Figure 8.5): Change the Name to "File1". Change the Remote File field to "/directory/file1.txt". Change the Username field to "anonymous". Change the Password field to "[email protected]". You do not have to set the Server Name field because you already specified this value in the FTP Request Defaults element. www.vskills.in

Page 49

Certified Jmeter Tester

Figure 8.5. FTP Request for file1

Next, add the second FTP Request and edit the following properties (see Figure 8.6: Change the Name to "File2". Change the Remote File field to "/directory/file2.txt". Change the Username field to "anonymous". Change the Password field to "[email protected]".

Figure 8.6. FTP Request for file2

8.4. Adding a Listener to View/Store the Test Results The final element you need to add to your Test Plan is a Listener . This element is responsible for storing all of the results of your FTP requests in a file and presenting a visual model of the data. Select the FTP Users element and add a View Results in Table listener ( Add --> Listener --> --> View Results in Table ). Run your test and view the results.

www.vskills.in

Page 50

Certified Jmeter Tester

Figure 8.7. View Results in Table Listener

www.vskills.in

Page 51

Certified Jmeter Tester

9. BUILDING AN LDAP TEST TEST PLAN In this section, you will learn how to create a basic Test Plan to test an LDAP server. You will create four users that send requests for four tests on the LDAP server. Also, you will tell the users to run their tests 4 times. So, the total number of requests is (4 users) x (4 requests) x repeat 4 times) = 40 LDAP requests. To construct the Test Plan, you will use the following elements: Thread Group , LDAP Request , LDAP Request Defaults , and View Results in Table . This example assumes that the LDAP Server is available at ldap.test.com.

9.1. Adding Users The first step you want to do with every JMeter Test Plan is to add a Thread Group element. The Thread Group tells JMeter the number of users you want to simulate, how often the users should send requests, and the how many requests they should send. Go ahead and add the ThreadGroup element by first selecting the Test Plan, clicking your right mouse button to get the Add menu, and then select Add> Add ThreadGroup . You should now see the Thread Group element under Test Plan. If you do not see the element, then "expand" the Test Plan tree by clicking on the Test Plan element.

Figure 9a.1. Thread Group and final test tree

9.2. Adding Login Config Element Begin by selecting the LDAP Users element. Click your right mouse button to get the Add menu, and then select Add > Config Element > Login Login Config Element . Then, select this new element to view its Control Panel. Like most JMeter elements, the Login Config Element 's Control Panel has a name field that you can modify. In this example, leave this field with the default value.

www.vskills.in

Page 52

Certified Jmeter Tester

Figure 9a.2 Login Config Element for our Test Plan

Enter Username field to "your LDAP Username", The password field to "your LDAP Passowrd" These values will be used by the LDAP Requests

9.3. Adding LDAP Request Defaults Begin by selecting the LDAP Users element. Click your right mouse button to get the Add menu, and then select Add > Config Element > LDAP Request Defaults . Then, select this new element to view its Control Panel. Like most JMeter elements, the LDAP Request Defaults Control Panel has a name field that you can modify. In this example, leave this field with the default value.

Figure 9a.3 LDAP Defaults for our Test Plan

Enter DN field to "your LDAP Root Distinguished Name". Enter LDAP Server's Servername field to "ldap.test.com". The port to 389. These values are default for the LDAP Requests.

9.4. Adding LDAP Requests In our Test Plan, we need to make four LDAP requests. Inbuilt Add Test Inbuilt Search Test Inbuilt Modify Test Inbuilt Delete Test

www.vskills.in

Page 53

Certified Jmeter Tester JMeter sends requests in the order that you add them to the tree. Start by adding the first LDAP Request to the LDAP Users element ( Add > Sampler> Sampler LDAP Request ). Then, select the LDAP Request element in the tree and edit the following properties Rename to "Add" this element Select the Add Test radio button in Test Configuration group

Figure 9a.4.1 LDAP Request for Inbuilt Add test

You do not have to set the Server Name field, port field, Username, Password and DN because you already specified this value in the Login Config Element and LDAP Request Defaults. Defaults Next, add the second LDAP Request and edit the following properties Rename to "Search" this element Select the Search Test radio button in Test Configuration group

Figure 9a.4.2 LDAP Request for Inbuilt Search test

Rename to "Modify" this element Select the Modify Test radio button in Test Configuration group

www.vskills.in

Page 54

Certified Jmeter Tester

Figure 9a.4.3 LDAP Request for Inbuilt Modify test

Rename to "Delete" this element Select the Delete Test radio button in Test Configuration group

Figure 9a.4.4 LDAP Request for Inbuilt Delete test

9.5. Adding a Listener to View/Store the Test Results You can add a Response Assertion element. This element will check the received response data by verifying if the response text is "successful". ( Add >Assertion > Response Assertion ). Note: A this position in the tree, the Response Assertion will be executed for each LDAP Request. Select Text Response Radio button in Response Field to Test group Select Substring Radio button in Pattern Matching Rules group Click on Add button and add the string "successful" in Pattern to Test field

www.vskills.in

Page 55

Certified Jmeter Tester

Figure 9a.5 LDAP Response Assertion

9a.6 Adding a Listener to View/Store the Test Results The final element you need to add to your Test Plan is a Listener. This element is responsible for storing all of the results of your LDAP requests in a file and presenting a visual model of the data. Select the LDAP Users element and add a View Results in Table ( Add > Listener > View Results in Table )

Figure 9a.6 View Results in Table Listener

9.6. Building an Extended LDAP Test Plan Plan In this section, you will learn how to create a basic Test Plan to test an LDAP server. As the Extended LDAP Sampler is highly configurable, this also means that it takes some time to build a correct testplan. You can however tune it exactly up to your needs.

www.vskills.in

Page 56

Certified Jmeter Tester You will create four users that send requests for four tests on the LDAP server. Also, you will tell the users to run their tests one time. So, the total number of requests is (1 users) x (9 requests) x repeat 1 time) = 9 LDAP requests. To construct the Test Plan, you will use the following elements: Thread Group , Adding LDAP Extended Request Defaults , Adding LDAP Requests , and Adding a Listener to View/Store the Test Results This example assumes that the LDAP Server is available at ldap.test.com. For the less experienced LDAP users, I build a small LDAP tutorial which shortly explains the several LDAP operations that can be used in building a complex testplan. Take care when using LDAP special characters in the distinguished name, in that case (eg, you want to use a + sign in a distinguished name) you need to escape the character by adding an "\" sign before that character. extra exception: if you want to add a \ character in a distinguished name (in an add or rename operation), you need to use 4 backslashes. examples: cn=dolf\+smits to add/search an entry with the name like cn=dolf+smits cn=dolf \\ smits to search an entry with the name cn=dolf \ smits cn=c:\\\\log.txt to add an entry with a name like cn=c:\log.txt

9.7. Adding Users The first step you want to do with every JMeter Test Plan is to add a Thread Group element. The Thread Group tells JMeter the number of users you want to simulate, how often the users should send requests, and the how many requests they should send. Go ahead and add the Thread Group element by first selecting the Test Plan , clicking your right mouse button to get the Add menu, and then select Add > Threads (Users Users) Users > Thread Group . You should now see the Thread Group element under Test Plan . If you do not see the element, then "expand" the Test Plan tree by clicking on the Test Plan element.

Figure 9b.1. Thread Group with Default Values

www.vskills.in

Page 57

Certified Jmeter Tester 9.8. Adding LDAP Extended Request Defaults Begin by selecting the LDAP Ext Users element. Click your right mouse button to get the Add menu, and then select Add > Config Element > LDAP Extended Request Defaults . Then, select this new element to view its Control Panel. Like most JMeter elements, the LDAP Extended Request Defaults Control Panel has a name field that you can modify. In this example, leave this field with the default value.

Figure 9b.2 LDAP Defaults for our Test Plan

For each of the different operations, some default values can be filled in. In All cases, when a default is filled in, this is used for the LDAP extended requests. For each request, you can override the defaults by filling in the values in the LDAP extended request sampler. When no value is entered which is necessary for a test, the test will fail in an unpredictable way!

9.9. Adding LDAP Requests In our Test Plan, we want to use all 9 LDAP requests. Thread bind Search Test Compare Test Single bind/unbind Test Add Test Modify Test Rename entry (moddn) Delete Test Thread unbind JMeter sends requests in the order that you add them to the tree. Adding a requests always start by: Adding the LDAP Extended Request to the LDAP Ext Users element ( Add > Sampler > LDAP Ext Request ). Then, select the LDAP Ext Request element in the tree and edit the following properties.

Adding a Thread bind Request Rename the element: "1. Thread bind" Select the "Thread bind" button. www.vskills.in

Page 58

Certified Jmeter Tester Enter the hostname value from the LDAP server in the Servername field Enter the portnumber from the LDAP server (636 : ldap over SSL) in the port field (Optional) Enter the baseDN in the DN field, this baseDN will be used as thestarting point for searches, add, deletes etc. take care that this must be the uppermost shared level for all your request, eg When all information is stored under ou=Users, dc=test, dc=com, you can use this value in the basedn. (Optional) Enter the distinguished name from the user you want to use for authentication. When this field is kept empty, an anonymous bind will be established. (Optional) Enter the password for the user you want to authenticate with, an empty password will also lead to an anonymous bind. (Optional) Enter a value for the connection timeout with LDAP (Optional) Check the box Use Secure LDAP Protocol if you access with LDAP over SSL (ldaps)

Figure 9b.3.1. Thread Bind example

Adding a search Request Rename the element: "2. Search Test" Select the "Search Test" button. Optional) enter the searchbase under which you want to perform the search, relative to the basedn, used in the thread bind request. When left empty, the basedn is used as a search base, this files is important if you want to use a "base-entry" or "one-level" search (see below) Enter the searchfilter, any decent LDAP search filter will do, but for now, use something simple, like (sn=Doe) or (cn=*) (Optional) Enter the scope in the scope field, it has three options: baseobject search only the given searchbase is used, only for checking attributes or existence. onelevel search Only search in one level below given searchbase is used

www.vskills.in

Page 59

Certified Jmeter Tester subtree search Searches for object at any point below the given basedn (Optional) Size limit, specifies the maximum number of returned entries, (Optional) Time limit, specifies the maximum number of milliseconds, the SERVER can use for performing the search. it is NOT the maximum time the application will wait. When a very large returnset is returned, from a very fast server, over a very slow line, you may have to wait for ages for the completion of the search request, but this parameter will not influence this. (Optional) Attributes you want in the search answer. This can be used to limit the size of the answer, especially when an object has very large attributes (like jpeg Photo). There are three possibilities: Leave empty (the default setting must also be empty) This will return all attributes. Put in one empty value (""), it will request a non-existent attributes, so in reality it returns no attributes Put in the attributes, separated by a semi-colon. It will return only the requested attributes (Optional) Return object. Checked will return all java-object attributes, it will add these to the requested attributes, as specified above. Unchecked will mean no java-object attributes will be returned. (Optional) Dereference aliases. Checked will mean it will follow references, Unchecked says it will not. Optional) Parse the search results?. Checked will mean it gets all results in response data, Unchecked says it will not.

Figure 9b.3.2. search request example

www.vskills.in

Page 60

Certified Jmeter Tester Adding a Compare Request Rename the element: "3. Compare Test" Select the "Compare" button. enter the entryname form the object on which you want the compare operation to work, relative to the basedn, eg "cn=jdoe,ou=Users" Enter the compare filter, this must be in the form "attribute=value", eg "[email protected]"

Figure 9b.3.3. Compare example

Adding a Single bind/unbind Rename the element: "4. Single bind/unbind Test" Select the "Single bind/unbind" button. Enter the FULL distinguished name from the user you want to use for authentication. eg. cn=jdoe,ou=Users,dc=test,dc=com When this field is kept empty, an anonymous bind will be established. 4. Enter the password for the user you want to authenticate with, an empty password will also lead to an anonymous bind. Take care : This single bind/unbind is in reality two separate operations but cannot easily be split!

Figure 9b.3.4. Single bind/unbind example

www.vskills.in

Page 61

Certified Jmeter Tester Adding an Add Request Rename the element: "5. Add Test" Select the "Add" button. Enter the distinguished name for the object to add, relative to the basedn. Add a line in the "add test" table, fill in the attribute and value. When you need the same attribute more than once, just add a new line, add the attribute again, and a different value. All necessary attributes and values must be specified to pass the test, see picture! (sometimes the server adds the attribute "objectClass=top", this might give a problem.

Figure 9b.3.5. Add request example

Adding a Modify Request Rename the element: "6. Modify Test" Select the "Modify test" button. Enter the distinguished name for the object to modify, relative to the basedn. Add a line in the "modify test" table, with the "add" button. You need to enter the attribute you want to modify, (optional) a value, and the opcode. The meaning of this opcode: 1. add this will mean that the attribute value (not optional in this case) will be added to the attribute. When the attribute is not existing, it will be created and the value added When it is existing, and defined multi-valued, the new value is added.

www.vskills.in

Page 62

Certified Jmeter Tester when it is existing, but single valued, it will fail. 2. replace This will overwrite the attribute with the given new value (not optional here) When the attribute is not existing, it will be created and the value added When it is existing, old values are removed, the new value is added. 3. delete delete When no value is given, all values will be removed When a value is given, only that value will be removed when the given value does not exist, the test will fail 6. (Optional) Add more modifications in the "modify test" table. All modifications which are specified must succeed, to let the modification test pass. When one modification fails, NO modifications at all will be made and the entry will remain unchanged.

Figure 9b.3.6. Modify example

Adding a Rename Request (moddn) Rename the element: "7. Rename entry (moddn)" Select the "Rename Entry" button. Enter the name of the entry, relative to the baseDN, in the "old entry name-Field". that is, if you want to rename "cn=Little John Doe,ou=Users", and you set the baseDN to "dc=test,dc=com", you need to enter "cn=John Junior Doe,ou=Users" in the old entry name-field. Enter the new name of the entry, relative to the baseDN, in the "new distinguished name-Field". when you only change the RDN, it will simply rename the entry when you also add a different subtree, eg you change from cn=john doe,ou=Users to cn=john doe,ou=oldusers, it will move the entry. You can also move a complete subtree (If your LDAP

www.vskills.in

Page 63

Certified Jmeter Tester server supports this!), eg ou=Users,ou=retired, to ou=oldusers,ou=users, this will move the complete subtree, plus all retired people in the subtree to the new place in the tree.

Figure 9b.3.8. Rename example

Adding a Delete Request Rename the element: "8. Delete Test" Select the "Delete" button. Enter the name of the entry, relative to the baseDN, in the Delete-Field. that is, if you want to remove "cn=John Junior Doe,ou=Users,dc=test,dc=com", and you set the baseDN to "dc=test,dc=com", you need to enter "cn=John Junior Doe,ou=Users" in the Deletefield.

Figure 9b.3.7. Delete example

Adding an unbind Request Rename the element: 9. Thread unbind" Select the "Thread unbind" button. This will be enough as it just closes the current connection. The information which is needed is already known by the system

www.vskills.in

Page 64

Certified Jmeter Tester

Figure 9b.3.9. Unbind example

9.10. Adding a Listener Listener to View/Store the Test Results The final element you need to add to your Test Plan is a Listener. This element is responsible for storing all of the results of your LDAP requests in a file and presenting a visual model of the data.Select the Thread group element and add a View Results Tree ( Add > Listener > View Results Tree )

Figure 9b.4. View Result Tree Listener

In this listener you have three tabs to view, the sampler result, the request and the response data. The sampler result just contains the response time, the returncode and return message The request gives a short description of the request that was made, in practice no relevant information is contained here. The response data contains the full details of the sent request, as well the full details of the received answer, this is given in a (self defined) xml-style. The full description can be found here.

www.vskills.in

Page 65

Certified Jmeter Tester

10. BUILDING A WEBSERVICE WEBSERVICE TEST PLAN In this section, you will learn how to create a Test Plan to test a WebService. You will create five users that send requests to One page. Also, you will tell the users to run their tests twice. So, the total number of requests is (5 users) x (1 requests) x (repeat 2 times) = 10 HTTP requests. To construct the Test Plan, you will use the following elements:Thread Group , WebService(SOAP) Request , and Graph Results . If the sampler appears to be getting an error from the web service, double check the SOAP message and make sure the format is correct. In particular, make sure the xmlns attributes are exactly the same as the WSDL. If the xml namespace is different, the web service will likely return an error. Xmethods contains a list of public web service for those who want to test their test plan.

10.1. Adding Users The first step you want to do with every JMeter Test Plan is to add a Thread Group element. The Thread Group tells JMeter the number of users you want to simulate, how often the users should send requests, and the how many requests they should send. Go ahead and add the ThreadGroup element by first selecting the Test Plan, clicking your right mouse button to get the Add menu, and then select Add --> ThreadGroup. You should now see the Thread Group element under Test Plan. If you do not see the element, then "expand" the Test Plan tree by clicking on the Test Plan element. Next, you need to modify the default properties. Select the Thread Group element in the tree, if you have not already selected it. You should now see the Thread Group Control Panel in the right section of the JMeter window (see Figure 10.1 below)

Figure 10.1. Thread Group with Default Values

Start by providing a more descriptive name for our Thread Group. In the name field, enter Jakarta Users. Next, increase the number of users (called threads) to 10. In the next field, the Ramp-Up Period, leave the default value of 0 seconds. This property tells JMeter how long to delay between starting each user. For example, if you enter a Ramp-Up Period

www.vskills.in

Page 66

Certified Jmeter Tester of 5 seconds, JMeter will finish starting all of your users by the end of the 5 seconds. So, if we have 5 users and a 5 second Ramp-Up Period, then the delay between starting users would be 1 second (5 users / 5 seconds = 1 user per second). If you set the value to 0, then JMeter will immediately start all of your users. Finally, clear the checkbox labeled "Forever", and enter a value of 2 in the Loop Count field. This property tells JMeter how many times to repeat your test. If you enter a loop count value of 0, then JMeter will run your test only once. To have JMeter repeatedly run your Test Plan, select the Forever checkbox. In most applications, you have to manually accept changes you make in a Control Panel. However, in JMeter, the Control Panel automatically accepts your changes as you make them. If you change the name of an element, the tree will be updated with the new text after you leave the Control Panel (for example, when selecting another tree element).

Figure 10.2. Jakarta Users Thread Group

10.2. Adding WebService Requests In our Test Plan, we will use a .NET web service. Since you're using the web service sampler, we won't go into the details of writing a web service. If you don't know how to write a web service, Google for web service and familiarize yourself with writing web services for Java and .NET. It should be noted there is a significant difference between how .NET and Java implement web services. The topic is too broad to cover in the user manual. Please refer to other sources to get a better idea of the differences. JMeter sends requests in the order that they appear in the tree. Start by adding the sampler WebService(SOAP) Request to the Jakarta Users element (Add --> Sampler --> WebService(SOAP) Request). Then, select the web service Request element in the tree and edit the following properties (see Figure 10.5): Change the Name field to "WebService(SOAP) Request". Enter the WSDL URL and click "Load WSDL".

www.vskills.in

Page 67

Certified Jmeter Tester

Figure 10.3. Web service Request

If the WSDL file was loaded correctly, the "Web Methods" drop down should be populated. If the drop down remains blank, it means there was a problem getting the WSDL. You can test the WSDL using a browser that reads XML. For example, if you're testing an IIS web service the URL will look like this: http://localhost/myWebService/Service.asmx?WSDL. At this point, SOAPAction, URL and SOAP Data should be blank. Next, select the web method and click "Configure". The sampler should populate the "URL" and "SOAPAction" text fields. Assuming the WSDL is valid, the correct soap action should be entered. The last step is to paste the SOAP message in the "SOAP/XML-RPC Data" text area. You can optionally save the soap message to a file and browse to the location. For convenience, there is a third option of using a message folder. The sampler will randomly select files from a given folder and use the text for the soap message. If you do not want JMeter to read the response from the SOAP Web service, uncheck "Read Soap Responses." If the test plan is intended to stress test a web service, the box should be unchecked. If the test plan is a functional test, the box should be checked. When "Read Soap Responses" is unchecked, no result will be displayed in view result tree or view results in table. An important note on the sampler. It will automatically use the proxy host and port passed to JMeter from command line, if those fields in the sampler are left blank. If a sampler has values in

www.vskills.in

Page 68

Certified Jmeter Tester the proxy host and port text field, it will use the ones provided by the user. If no host or port are provided and JMeter wasn't started with command line options, the sampler will fail silently. This behavior may not be what users expect.

Note: If you're using Cassini web server, it does not work correctly and is not a reliable web server. Cassini is meant to be a simple example and isn't a full blown web server like IIS. Cassini does not close connections correctly, which causes JMeter to hang or not get the response contents. Currently, only .NET uses SOAPAction, so it is normal to have a blank SOAPAction for all other web services. The list includes JWSDP, Weblogic, Axis, The Mind Electric Glue, and gSoap.

Adding a Listener to View Store the Test Results The final element you need to add to your Test Plan is a Listener . This element is responsible for storing all of the results of your HTTP requests in a file and presenting a visual model of the data. Select the Jakarta Users element and add a Graph Results listener (Add --> Listener --> Graph Results). Next, you need to specify a directory and filename of the output file. You can either type it into the filename field, or select the Browse button and browse to a directory and then enter a filename.

Figure 10.7. Graph Results Listener

www.vskills.in

Page 69

Certified Jmeter Tester

11. BUILDING A JMS POINTPOINT-TOTO-POINT TEST PLAN In this section, you will learn how to create a Test Plan to test a JMS Point-to-Point messaging solution. The setup of the test is 1 threadgroup with 5 threads sending 4 messages each through a request queue. A fixed reply queue will be used for monitoring the reply messages. To construct the Test Plan, you will use the following elements: Thread Group , JMS Point-to-Point , and Graph Results . General notes on JMS: There are currently two JMS samplers. One uses JMS topics and the other uses queues. Topic messages are commonly known as pub/sub messaging. Topic messaging is generally used in cases where a message is published by a producer and consumed by multiple subscribers. A JMS sampler needs the JMS implementation jar files; for example, from Apache ActiveMQ. See here for the list of jars provided by ActiveMQ 3.0.

11.1. Adding a Thread Group The first step you want to do with every JMeter Test Plan is to add a Thread Group element. The Thread Group tells JMeter the number of users you want to simulate, how often the users should send requests, and the how many requests they should send. Go ahead and add the ThreadGroup element by first selecting the Test Plan, clicking your right mouse button to get the Add menu, and then select Add --> ThreadGroup. You should now see the Thread Group element under Test Plan. If you do not see the element, then "expand" the Test Plan tree by clicking on the Test Plan element. Next, you need to modify the default properties. Select the Thread Group element in the tree, if you have not already selected it. You should now see the Thread Group Control Panel in the right section of the JMeter window (see Figure 11.1 below)

Figure 11.1. Thread Group with Default Values

Start by providing a more descriptive name for our Thread Group. In the name field, enter Pointto-Point. Next, increase the number of users (called threads) to 5.

www.vskills.in

Page 70

Certified Jmeter Tester In the next field, the Ramp-Up Period, leave set the value to 0 seconds. This property tells JMeter how long to delay between starting each user. For example, if you enter a Ramp-Up Period of 5 seconds, JMeter will finish starting all of your users by the end of the 5 seconds. So, if we have 5 users and a 5 second Ramp-Up Period, then the delay between starting users would be 1 second (5 users / 5 seconds = 1 user per second). If you set the value to 0, then JMeter will immediately start all of your users. Clear the checkbox labeled "Forever", and enter a value of 4 in the Loop Count field. This property tells JMeter how many times to repeat your test. If you enter a loop count value of 0, then JMeter will run your test only once. To have JMeter repeatedly run your Test Plan, select the Forever checkbox. In most applications, you have to manually accept changes you make in a Control Panel. However, in JMeter, the Control Panel automatically accepts your changes as you make them. If you change the name of an element, the tree will be updated with the new text after you leave the Control Panel (for example, when selecting another tree element).

11.2. Adding JMS PointPoint-toto-Point Sampler Start by adding the sampler JMS Point-to-Point to the Point-to-Point element (Add --> Sampler --> JMS Point-to-Point). Then, select the JMS Point-to-Point sampler element in the tree. In building the example a configuration will be provided that works with ActiveMQ 3.0.

11.3. Adding a Listener to View Store the Test Results The final element you need to add to your Test Plan is a Listener . This element is responsible for storing all of the results of your JMS requests in a file and presenting a visual model of the data. Select the Thread Group element and add a Graph Results listener (Add --> Listener --> Graph Results). Next, you need to specify a directory and filename of the output file. You can either type it into the filename field, or select the Browse button and browse to a directory and then enter a filename.

www.vskills.in

Page 71

Certified Jmeter Tester

Figure 11.2. Graph Results Listener

www.vskills.in

Page 72

Certified Jmeter Tester

12. BUILDING A JMS TOPIC TEST PLAN In this section, you will learn how to create a Test Plan to test JMS Providers. You will create five subscribers and one publisher. You will create 2 thread groups and set each one to 10 iterations. The total messages is (6 threads) x (1 message) x (repeat 10 times) = 60 messages. To construct the Test Plan, you will use the following elements: Thread Group , JMS Publisher , JMS Subscriber , and Graph Results . General notes on JMS: There are currently two JMS samplers. One uses JMS topics and the other uses queues. Topic messages are commonly known as pub/sub messaging. Topic messaging is generally used in cases where a message is published by a producer and consumed by multiple subscribers. Queue messaging is generally used for transactions where the sender expects a response. Messaging systems are quite different from normal HTTP requests. In HTTP, a single user sends a request and gets a response. Messaging system can work in synchronous and asynchronous mode. A JMS sampler needs the JMS implementation jar files; for example, from Apache ActiveMQ. See here for the list of jars provided by ActiveMQ 3.0.

12.1. Adding Users The first step is adding a Thread Group element. The Thread Group tells JMeter the number of users you want to simulate, how often the users should send requests, and how many requests they should send. Go ahead and add the ThreadGroup element by first selecting the Test Plan, clicking your right mouse button to get the Add menu, and then select Add --> ThreadGroup. You should now see the Thread Group element under Test Plan. If you do not see the element, then "expand" the Test Plan tree by clicking on the Test Plan element. Next, you need to modify the default properties. Select the Thread Group element in the tree, if you have not already selected it. You should now see the Thread Group Control Panel in the right section of the JMeter window (see Figure 12.1 below)

Figure 12.1. Thread Group with Default Values

Start by providing a more descriptive name for our Thread Group. In the name field, enter Subscribers.

www.vskills.in

Page 73

Certified Jmeter Tester Next, increase the number of users (called threads) to 5. In the next field, the Ramp-Up Period, set the value to 0 seconds. This property tells JMeter how long to delay between starting each user. For example, if you enter a Ramp-Up Period of 5 seconds, JMeter will finish starting all of your users by the end of the 5 seconds. So, if we have 5 users and a 5 second Ramp-Up Period, then the delay between starting users would be 1 second (5 users / 5 seconds = 1 user per second). If you set the value to 0, JMeter will immediately start all users. Clear the checkbox labeled "Forever", and enter a value of 10 in the Loop Count field. This property tells JMeter how many times to repeat your test. If you enter a loop count value of 0, then JMeter will run your test only once. To have JMeter repeatedly run your Test Plan, select the Forever checkbox. Repeat the process and add another thread group. For the second thread group, enter "Publisher" in the name field, set the number of threads to 1, and set the iteration to 10.

12.2. Adding JMS Subscriber and Publisher Make sure the required jar files are in JMeter's lib directory. If they are not, shutdown JMeter, copy the jar files over and restart JMeter. Start by adding the sampler JMS Subscriber to the Subscribers element (Add --> Sampler --> JMS Subscriber). Then, select the JMS Subscriber element in the tree and edit the following properties: Change the Name field to "Sample Subscriber" If the JMS provider uses the jndi.properties file, check the box Enter the name of the InitialContextFactory class. For example, with ActiveMQ 5.4, the value is "org.apache.activemq.jndi.ActiveMQInitialContextFactory" Enter the provider URL. This is the URL for the JNDI server, if there is one. For example, with ActiveMQ 5.4 on local machine with default port, the value is "tcp://localhost:61616" Enter the name of the connection factory. Please refer to the documentation of the JMS provider for the information. For ActiveMQ, the default is "ConnectionFactory" Enter the name of the message topic. For ActiveMQ Dynamic Topics (create topics dynamically), example value is "dynamicTopics/MyStaticTopic1" Note: Setup at startup mean that JMeter starting to listen on the Destination at beginning of test without name change possibility. Setup on Each sample mean that JMeter (re)starting to listen before run each JMS Subscriber sample, this last option permit to have Destination name with some JMeter variables If the JMS provider requires authentication, check "required" and enter the username and password. For example, Orion JMS requires authentication, while ActiveMQ and MQSeries does not Enter 10 in "Number of samples to aggregate". For performance reasons, the sampler will aggregate messages, since small messages will arrive very quickly. If the sampler didn't aggregate the messages, JMeter wouldn't be able to keep up. If you want to read the response, check the box

www.vskills.in

Page 74

Certified Jmeter Tester There are two client implementations for subscribers. If the JMS provider exhibits zombie threads with one client, try the other.

Figure 12.2. JMS Subscriber

Next add the sampler JMS Publisher to the Publisher element (Add --> Sampler --> JMS Subscriber). Then, select the JMS Publisher element in the tree and edit the following properties: Change the Name field to "Sample Publisher". If the JMS provider uses the jndi.properties file, check the box Enter the name of the InitialContextFactory class. For example, with ActiveMQ 5.4, the value is "org.apache.activemq.jndi.ActiveMQInitialContextFactory" Enter the provider URL. This is the URL for the JNDI server, if there is one. For example, with ActiveMQ 5.4 on local machine with default port, the value is "tcp://localhost:61616" Enter the name of the connection factory. Please refer to the documentation of the JMS provider for the information. For ActiveMQ, the default is "ConnectionFactory" Enter the name of the message topic. For ActiveMQ Dynamic Topics (create topics dynamically), example value is "dynamicTopics/MyStaticTopic1". Note: Setup at startup mean that JMeter starting connection with the Destination at beginning of test without name change possibility. Setup on Each sample mean that JMeter (re)starting the connection before run each JMS Publisher sample, this last option permit to have Destination name with some JMeter variables If the JMS provider requires authentication, check "required" and enter the username and password. For example, Orion JMS requires authentication, while ActiveMQ and MQSeries does not

www.vskills.in

Page 75

Certified Jmeter Tester

Enter 10 in "Number of samples to aggregate". For performance reasons, the sampler will aggregate messages, since small messages will arrive very quickly. If the sampler didn't aggregate the messages, JMeter wouldn't be able to keep up. Select the appropriate configuration for getting the message to publish. If you want the sampler to randomly select the message, place the messages in a directory and select the directory using browse. Select the message type. If the message is in object format or map message, make sure the message is generated correctly.

Figure 12.3. JMS Publisher

12.3. Adding a Listener to View Store the Test Results The final element you need to add to your Test Plan is a Listener . This element is responsible for storing all of the results of your HTTP requests in a file and presenting a visual model of the data. Select the Test Plan element and add a Graph Results listener (Add --> Listener --> Graph Results). Next, you need to specify a directory and filename of the output file. You can either type it into the filename field, or select the Browse button and browse to a directory and then enter a filename.

www.vskills.in

Page 76

Certified Jmeter Tester

Figure 12.4. Graph Results Listener

www.vskills.in

Page 77

Certified Jmeter Tester

13. BUILDING A MONITOR TEST TEST PLAN In this section, you will learn how to create a Test Plan to monitor web servers. Monitors are useful for a stress testing and system management. Used with stress testing, the monitor provides additional information about server performance. It also makes it easier to see the relationship between server performance and response time on the client side. As a system administration tool, the monitor provides an easy way to monitor multiple servers from one console. The monitor was designed to work with the status servlet in Tomcat 5. In theory, any servlet container that supports JMX (Java Management Extension) can port the status servlet to provide the same information. For those who want to use the monitor with other servlet or EJB containers, Tomcat's status servlet should work with other containers for the memory statistics without any modifications. To get thread information, you will need to change the MBeanServer lookup to retrieve the correct MBeans.

13.1. Adding A Server The first step is to add a Thread Group element. The Thread Group tells JMeter the number of threads you want. Always use 1, since we are using JMeter as a monitor. This is very important for those not familiar with server monitors. As a general rule, using multiple threads for a single server is bad and can create significant stress. Go ahead and add the ThreadGroup element by first selecting the Test Plan, clicking your right mouse button to get the Add menu, and then select Add --> ThreadGroup. You should now see the Thread Group element under Test Plan. If you do not see the element, "expand" the Test Plan tree by clicking on the Test Plan element.

Figure 13.1. Thread Group with Default Values

Change the loop count to forever (or some large number) so that enough samples are generated.

13.2. HTTP Auth Manager Add the HTTP Authorization Manager to the Thread Group element (Add --> Config element --> HTTP Authorization Manager). Enter the username and password for your web server. Important

www.vskills.in

Page 78

Certified Jmeter Tester note: the monitor only works with Tomcat5 build 5.0.19 and newer. For instructions on how to setup Tomcat, please refer to tomcat 5 documentation. leave the base URL blank enter the username enter the password

13.3. Adding HTTP Request Add the HTTP Request to the Thread Group element (Add --> Sampler --> HTTP Request). Then, select the HTTP Request element in the tree and edit the following properties): Change the Name field to "Server Status". Enter the IP address or Hostname Enter the port number Set the Path field to "/manager/status" if you're using Tomcat. Add a request parameter named "XML" in uppercase. Give it a value of "true" in lowercase. Check "Use as Monitor" at the bottom of the sampler

13.4. Adding Constant Timer Add a timer to this thread group (Add --> Timer --> Constant Timer). Enter 5000 milliseconds in the "Thread Delay" box. In general, using intervals shorter than 5 seconds will add stress to your server. Find out what is an acceptable interval before you deploy the monitor in your production environment.

13.5. Adding a Listener to Store the Results If you want to save the raw results from the server, add a simple data Listener . If you want to save the calculated statistics, enter a filename in the listener. If you want to save both the raw data and statistics, make sure you use different filenames. Select the thread group element and add a Simple Data Writer listener (Add --> Listener --> Simple Data Writer). Next, you need to specify a directory and filename of the output file. You can either type it into the filename field, or select the Browse button and browse to a directory and then enter a filename.

13.6. Adding Monitor Results Add the Listener by selecting the test plan element (Add --> Listener -- > Monitor Results). By default, the Listener will select the results from the first connector in the sample response. The Connector prefix field can be used to select a different connector. If specified, the Listener will choose the first connector which matches the prefix. If no match is found, then the first connector is selected.

www.vskills.in

Page 79

Certified Jmeter Tester

There are two tabs in the monitor results listener. The first is the "Health", which displays the status of the last sample the monitor received. The second tab is "Performance", which shows a historical view of the server's performance. A quick note about how health is calculated. Typically, a server will crash if it runs out of memory, or reached the maximum number of threads. In the case of Tomcat 5, once the threads are maxed out, requests are placed in a queue until a thread is available. The relative importance of threads vary between containers, so the current implementation uses 50/50 to be conservative. A container that is more efficient with thread management might not see any performance degradation, but the used memory definitely will show an impact.

www.vskills.in

Page 80

Certified Jmeter Tester

The performance graph shows four different lines. The free memory line shows how much free memory is left in the current allocated block. Tomcat 5 returns the maximum memory, but it is not graphed. In a well tuned environment, the server should never reach the maximum memory. Note the graph has captions on both sides of the graph. On the left is percent and the right is dead/healthy. If the memory line spikes up and down rapidly, it could indicate memory thrashing. In those situations, it is a good idea to profile the application with Borland OptimizeIt or JProbe. What you want to see is a regular pattern for load, memory and threads. Any erratic behavior usually indicates poor performance or a bug of some sort.

www.vskills.in

Page 81

Certified Jmeter Tester

14. INTRODUCTION TO LISTENERS LISTENERS A listener is a component that shows the results of the samples. The results can be shown in a tree, tables, graphs or simply written to a log file. To view the contents of a response from any given sampler, add either of the Listeners "View Results Tree" or "View Results in table" to a test plan. To view the response time graphically, add graph results, spline results or distribution graph. The listeners section of the components page has full descriptions of all the listeners. The "Configure" button can be used to specify which fields to write to the file, and whether to write it as CSV or XML. CSV files are much smaller than XML files, so use CSV if you are generating lots of samples. The file name can be specified using either a relative or an absolute path name. Relative paths are resolved relative to the current working directory (which defaults to the bin/ directory). Versions of JMeter after 2.4 also support paths relative to the directory containing the current test plan (JMX file). If the path name begins with "~/" (or whatever is in the jmeter.save.saveservice.base_prefix JMeter property), then the path is assumed to be relative to the JMX file location. If you only wish to record certain samples, add the Listener as a child of the sampler. Or you can use a Simple Controller to group a set of samplers, and add the Listener to that. The same filename can be used by multiple samplers - but make sure they all use the same configuration!

14.1. Default Configuration The default items to be saved can be defined in the jmeter.properties (or user.properties) file. The properties are used as the initial settings for the Listener Config pop-up, and are also used for the log file specified by the -l command-line flag (commonly used for non-GUI test runs). To change the default format, find the following line in jmeter.properties: jmeter.save.saveservice.output_format= The information to be saved is configurable. For maximum information, choose "xml" as the format and specify "Functional Test Mode" on the Test Plan element. If this box is not checked, the default saved data includes a time stamp (the number of milliseconds since midnight, January 1, 1970 UTC), the data type, the thread name, the label, the response time, message, and code, and a success indicator. If checked, all information, including the full response data will be logged. The following example indicates how to set properties to get a vertical bar ("|") delimited format that will output results like:.

The corresponding jmeter.properties that need to be set are shown below. One oddity in this example is that the output_format is set to csv, which typically indicates comma-separated values.

www.vskills.in

Page 82

Certified Jmeter Tester

However, the default_delimiter was set to be a vertical bar instead of a comma, so the csv tag is a misnomer in this case. (Think of CSV as meaning character separated values)

The full set of properties that affect result file output is shown below. #--------------------------------------------------------------------------# Results file configuration #--------------------------------------------------------------------------# This section helps determine how result data will be saved. # The commented out values are the defaults. # legitimate values: xml, csv, db. Only xml and csv are currently supported. #jmeter.save.saveservice.output_format=csv # true when field should be saved; false otherwise # assertion_results_failure_message only affects CSV output #jmeter.save.saveservice.assertion_results_failure_message=false # #jmeter.save.saveservice.data_type=true #jmeter.save.saveservice.label=true #jmeter.save.saveservice.response_code=true # response_data is not currently supported for CSV output #jmeter.save.saveservice.response_data=false # Save ResponseData for failed samples #jmeter.save.saveservice.response_data.on_error=false #jmeter.save.saveservice.response_message=true #jmeter.save.saveservice.successful=true #jmeter.save.saveservice.thread_name=true #jmeter.save.saveservice.time=true #jmeter.save.saveservice.subresults=true #jmeter.save.saveservice.assertions=true #jmeter.save.saveservice.latency=true #jmeter.save.saveservice.samplerData=false #jmeter.save.saveservice.responseHeaders=false #jmeter.save.saveservice.requestHeaders=false #jmeter.save.saveservice.encoding=false #jmeter.save.saveservice.bytes=true #jmeter.save.saveservice.url=false #jmeter.save.saveservice.filename=false #jmeter.save.saveservice.hostname=false #jmeter.save.saveservice.thread_counts=false

www.vskills.in

Page 83

Certified Jmeter Tester #jmeter.save.saveservice.sample_count=false #jmeter.save.saveservice.idle_time=false # Timestamp format # legitimate values: none, ms, or a format suitable for SimpleDateFormat #jmeter.save.saveservice.timestamp_format=ms #jmeter.save.saveservice.timestamp_format=yyyy/MM/dd HH:mm:ss.SSS # Put the start time stamp in logs instead of the end sampleresult.timestamp.start=true # Whether to use System.nanoTime() - otherwise only use System.currentTimeMillis() #sampleresult.useNanoTime=true # Use a background thread to calculate the nanoTime offset # Set this to - which is probably not what was intended. Note: although the above expression works, it's more efficient to use the following expression: name="file" value="([^"]+)"> where [^"] - means match anything except " In this case, the matching engine can stop looking as soon as it sees the first " , whereas in the previous case the engine has to check that it has found "> rather than say " > .

Extract multiple strings Suppose you want to match the following portion of a web-page: name="file.name" value="readme.txt" and you want to extract bothfile.name and readme.txt . A suitable regular expression would be: name="([^"]+)" value="([^"]+)" This would create 2 groups, which could be used in the JMeter Regular Expression Extractor template as $1$ and $2$. The JMeter Regex Extractor saves the values of the groups in additional variables. For example, assume: Reference Name: MYREF Regex: name="(.+?)" value="(.+?)" Template: $1$$2$ The following variables would be set: MYREF: file.namereadme.txt MYREF_g0: name="file.name" value="readme.txt" MYREF_g1: file.name MYREF_g2: readme.txt These variables can be referred to later on in the JMeter test plan, as ${MYREF}, ${MYREF_g1} etc

www.vskills.in

Page 129

Certified Jmeter Tester 19.3. Line mode The pattern matching behaves in various slightly different ways, depending on the setting of the multi-line and single-line modifiers. Note that the single-line and multi-line operators have nothing to do with each other; they can be specified independently.

SingleSingle-line mode Single-line mode only affects how the '.' meta-character is interpreted. Default behavior is that '.' matches any character except newline. In single-line mode, '.' also matches newline.

MultiMulti-line mode Multi-line mode only affects how the meta-characters '^' and '$' are interpreted. Default behavior is that '^' and '$' only match at the very beginning and end of the string. When Multi-line mode is used, the '^' metacharacter matches at the beginning of every line, and the '$' metacharacter matches at the end of every line.

19.4. Meta characters Regular expressions use certain characters as meta characters - these characters have a special meaning to the RE engine. Such characters must be escaped by preceding them with \ (backslash) in order to treat them as ordinary characters. Here is a list of the meta characters and their meaning (please check the ORO documentation if in doubt). ( ) - grouping [ ] - character classes { } - repetition * + ? - repetition . - wild-card character \ - escape character | - alternatives ^ $ - start and end of string or line The following Perl5 extended regular expressions are supported by ORO. (?#text) An embedded comment causing text to be ignored. (?:regexp) Groups things like "()" but doesn't cause the group match to be saved. (?=regexp) A zero-width positive lookahead assertion. For example, \w+(?=\s) matches a word followed by white space, without including white space in the MatchResult. www.vskills.in

Page 130

Certified Jmeter Tester

(?!regexp) A zero-width negative lookahead assertion. For example foo(?!bar) matches any occurrence of "foo" that isn't followed by "bar". Remember that this is a zero-width assertion, which means that a(?!b)d will match ad because a is followed by a character that is not b (the d) and a d follows the zero-width assertion. (?imsx) One or more embedded pattern-match modifiers. i enables case insensitivity, m enables multiline treatment of the input, s enables single line treatment of the input, and x enables extended white space comments. Note that (?