Ssl Setup Apache Windows

Feb 22, 2013. Follow below instructions to install the SSL on Apache. Ensure port 443 is open on window; Click on the Windows Start Button; Click Windows Firewall; When the Firewall window opens look the the Advanced settings on the left hand side of the window; When the Advanced Firewall wondows opens, look. Installing Tomcat on Windows can be done easily using the Windows installer. Its interface and functionality is similar to other wizard based installers, with.

This sampler lets you send an HTTP/HTTPS request to a web server. It also lets you control whether or not JMeter parses HTML files for images and other embedded resources and sends HTTP requests to retrieve them. The following types of embedded resource are retrieved: • images • applets • stylesheets (CSS) and resources referenced from those files • external scripts • frames, iframes • background images (body, table, TD, TR) • background sound The default parser is org.apache.jmeter.protocol.http.parser.LagartoBasedHtmlParser. This can be changed by using the property ' htmlparser.className' - see jmeter.properties for details. If you are going to send multiple requests to the same web server, consider using an Configuration Element so you do not have to enter the same information for each HTTP Request. Or, instead of manually adding HTTP Requests, you may want to use JMeter's to create them. This can save you time if you have a lot of HTTP requests or requests with many parameters.

There are two different test elements used to define the samplers: AJP/1.3 Sampler uses the Tomcat mod_jk protocol (allows testing of Tomcat in AJP mode without needing Apache httpd) The AJP Sampler does not support multiple file upload; only the first file will be used. HTTP Request this has an implementation drop-down box, which selects the HTTP protocol implementation to be used: Java uses the HTTP implementation provided by the JVM.

This has some limitations in comparison with the HttpClient implementations - see below. HTTPClient4 uses Apache HttpComponents HttpClient 4.x. Blank Value does not set implementation on HTTP Samplers, so relies on HTTP Request Defaults if present or on jmeter.httpsampler property defined in jmeter.properties The Java HTTP implementation has some limitations: • There is no control over how connections are re-used. When a connection is released by JMeter, it may or may not be re-used by the same thread. • The API is best suited to single-threaded usage - various settings are defined via system properties, and therefore apply to all connections.

• There is a bug in the handling of HTTPS via a Proxy (the CONNECT is not handled correctly). See Java bugs 6226610 and 6208335. • It does not support virtual hosts. • It supports only the following methods: GET, POST, HEAD, OPTIONS, PUT, DELETE and TRACE • It does not support client based certificate testing with Keystore Config. If the request requires server or proxy login authorization (i.e. Where a browser would create a pop-up dialog box), you will also have to add an Configuration Element.

For normal logins (i.e. Where the user enters login information in a form), you will need to work out what the form submit button does, and create an HTTP request with the appropriate method (usually POST) and the appropriate parameters from the form definition. If the page uses HTTP, you can use the JMeter Proxy to capture the login sequence.

A separate SSL context is used for each thread. If you want to use a single SSL context (not the standard behaviour of browsers), set the JMeter property: https.sessioncontext.shared=true By default, the SSL context is retained for the duration of the test.

The SSL session can be optionally reset for each test iteration. To enable this, set the JMeter property: https.use.cached.ssl.context=false. JMeter defaults to the SSL protocol level TLS. If the server needs a different level, e.g. SSLv3, change the JMeter property, for example: https.default.protocol=SSLv3 JMeter also allows one to enable additional protocols, by changing the property https.socket.protocols. If the request uses cookies, then you will also need an. You can add either of these elements to the Thread Group or the HTTP Request.

If you have more than one HTTP Request that needs authorizations or cookies, then add the elements to the Thread Group. That way, all HTTP Request controllers will share the same Authorization Manager and Cookie Manager elements. If the request uses a technique called 'URL Rewriting' to maintain sessions, then see section for additional configuration steps. This only has any effect if ' Redirect Automatically' is not enabled. If set, the JMeter sampler will check if the response is a redirect and follow it if so. The initial redirect and further responses will appear as additional samples.

The URL and data fields of the parent sample will be taken from the final (non-redirected) sample, but the parent byte count and elapsed time include all samples. The latency is taken from the initial response. Note that the HttpClient sampler may log the following message: 'Redirect requested but followRedirects is disabled' This can be ignored.

JMeter will collapse paths of the form ' /./segment' in both absolute and relative redirect URLs. For example will be collapsed into If necessary, this behaviour can be suppressed by setting the JMeter property httpsampler.redirect.removeslashdotdot=false. The query string will be generated from the list of parameters you provide. Each parameter has a name and value, the options to encode the parameter, and an option to include or exclude an equals sign (some applications don't expect an equals sign when the value is the empty string). The query string will be generated in the correct fashion, depending on the choice of 'Method' you made (i.e. If you chose GET or DELETE, the query string will be appended to the URL, if POST or PUT, then it will be sent separately).

Also, if you are sending a file using a multipart form, the query string will be created using the multipart form specifications. See below for some further information on parameter handling. Additionally, you can specify whether each parameter should be URL encoded.

If you are not sure what this means, it is probably best to select it. If your values contain characters such as the following then encoding is usually required.: • ASCII Control Chars • Non-ASCII characters • Reserved characters:URLs use some characters for special use in defining their syntax. When these characters are not used in their special role inside a URL, they need to be encoded, example: ' $', ' &', ' +', ',', ' /', ':', ';', ' =', '?' , ' @' • Unsafe characters: Some characters present the possibility of being misunderstood within URLs for various reasons. These characters should also always be encoded, example: ' ', ' ', ' #', '%'.

Name of the file to send. If left blank, JMeter does not send a file, if filled in, JMeter automatically sends the request as a multipart form request. If it is a POST or PUT or PATCH request and there is a single file whose 'Parameter name' attribute (below) is omitted, then the file is sent as the entire body of the request, i.e. No wrappers are added. This allows arbitrary bodies to be sent. This functionality is present for POST requests, and also for PUT requests.

See below for some further information on parameter handling. When using Automatic Redirection, cookies are only sent for the initial URL. This can cause unexpected behaviour for web-sites that redirect to a local server. If www.example.com redirects to www.example.co.uk.

In this case the server will probably return cookies for both URLs, but JMeter will only see the cookies for the last host, i.e. If the next request in the test plan uses www.example.com, rather than www.example.co.uk, it will not get the correct cookies. Likewise, Headers are sent for the initial request, and won't be sent for the redirect. This is generally only a problem for manually created test plans, as a test plan created using a recorder would continue from the redirected URL. Parameter Handling: For the POST and PUT method, if there is no file to send, and the name(s) of the parameter(s) are omitted, then the body is created by concatenating all the value(s) of the parameters.

Note that the values are concatenated without adding any end-of-line characters. These can be added by using the function in the value fields.

This allows arbitrary bodies to be sent. The values are encoded if the encoding flag is set. See also the MIME Type above how you can control the content-type request header that is sent. For other methods, if the name of the parameter is missing, then the parameter is ignored. This allows the use of optional parameters defined by variables. You have the option to switch to Body Data tab when a request has only unnamed parameters (or no parameters at all).

This option is useful in the following cases (amongst others): • GWT RPC HTTP Request • JSON REST HTTP Request • XML REST HTTP Request • SOAP HTTP Request. In Body Data mode, each line will be sent with CRLF appended, apart from the last line. To send a CRLF after the last line of data, just ensure that there is an empty line following it. (This cannot be seen, except by noting whether the cursor can be placed on the subsequent line.) Figure 1 - HTTP Request with one unnamed parameter Figure 2 - Confirm dialog to switch Figure 3 - HTTP Request using Body Data Method Handling: The GET, DELETE, POST, PUT and PATCH request methods work similarly, except that as of 3.1, only POST method supports multipart requests or file upload. The PUT and PATCH method body must be provided as one of the following: • define the body as a file with empty Parameter name field; in which case the MIME Type is used as the Content-Type • define the body as parameter value(s) with no name • use the Body Data tab The GET, DELETE and POST methods have an additional way of passing parameters by using the Parameters tab. GET, DELETE, PUT and PATCH require a Content-Type. If not using a file, attach a Header Manager to the sampler and define the Content-Type there.

JMeter scan responses from embedded resources. It uses the property HTTPResponse.parsers, which is a list of parser ids, e.g. HtmlParser, cssParser and wmlParser. For each id found, JMeter checks two further properties: • id.types - a list of content types • id.className - the parser to be used to extract the embedded resources See jmeter.properties file for the details of the settings. If the HTTPResponse.parser property is not set, JMeter reverts to the previous behaviour, i.e. Only text/html responses will be scanned Emulating slow connections: HttpClient4 and Java Sampler support emulation of slow connections; see the following entries in jmeter.properties: # Define characters per second >0 to emulate slow connections #httpclient.socket.http.cps=0 #httpclient.socket.https.cps=0 However the Java sampler only supports slow HTTPS connections.

Response size calculation Optional properties to allow change the method to get response size: • Gets the real network size in bytes for the body response sampleresult.getbytes.body_real_size=true • Add HTTP headers to full response size sampleresult.getbytes.headers_size=true. Retry handling For HttpClient4 the retry count has been set to 0, meaning not retry is attempted.

Note that the Java implementation appears to retry 1 time. The retry count can be overridden by setting the relevant JMeter property, for example: httpclient4.retrycount=3 httpclient4.request_sent_retry_enabled=true Note: Certificates does not conform to algorithm constraints You may encounter the following error: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints if you run a HTTPS request on a web site with a SSL certificate (itself or one of SSL certificates in its chain of trust) with a signature algorithm using MD2 (like md2WithRSAEncryption) or with a SSL certificate with a size lower than 1024 bits.

This error is related to increased security in Java 8. To allow you to perform your HTTPS request, you can downgrade the security of your Java installation by editing the Java jdk.certpath.disabledAlgorithms property. Remove the MD2 value or the constraint on size, depending on your case. This property is in this file: JAVA_HOME/jre/lib/security/java.security See for details. This sampler lets you send a JDBC Request (an SQL query) to a database. Before using this you need to set up a Configuration element If the Variable Names list is provided, then for each row returned by a Select statement, the variables are set up with the value of the corresponding column (if a variable name is provided), and the count of rows is also set up. For example, if the Select statement returns 2 rows of 3 columns, and the variable list is A,,C, then the following variables will be set up: A_#=2 (number of rows) A_1=column 1, row 1 A_2=column 1, row 2 C_#=2 (number of rows) C_1=column 3, row 1 C_2=column 3, row 2 If the Select statement returns zero rows, then the A_# and C_# variables would be set to 0, and no other variables would be set.

Old variables are cleared if necessary - e.g. If the first select retrieves six rows and a second select returns only three rows, the additional variables for rows four, five and six will be removed. If the callable statement has INOUT or OUT parameters, then these must be indicated by prefixing the appropriate parameter types, e.g. Instead of ' INTEGER', use ' INOUT INTEGER'. If not specified, ' IN' is assumed, i.e. ' DATE' is the same as ' IN DATE'. If the type is not one of the fields found in java.sql.Types, JMeter also accepts the corresponding integer number, e.g.

Since OracleTypes.CURSOR == -10, you can use ' INOUT -10'. There must be as many types as there are placeholders in the statement. Comma-separated list of variable names to hold values returned by Select statements, Prepared Select Statements or CallableStatement. Note that when used with CallableStatement, list of variables must be in the same sequence as the OUT parameters returned by the call. If there are less variable names than OUT parameters only as many results shall be stored in the thread-context variables as variable names were supplied. If more variable names than OUT parameters exist, the additional variables will be ignored. Defines how ResultSet returned from callable statements be handled: • Store As String (default) - All variables on Variable Names list are stored as strings, will not iterate through a ResultSet when present on the list.

CLOBs will be converted to Strings. BLOBs will be converted to Strings as if they were an UTF-8 encoded byte-array. Both CLOBs and BLOBs will be cut off after jdbcsampler.max_retain_result_size bytes. • Store As Object - Variables of ResultSet type on Variables Names list will be stored as Object and can be accessed in subsequent tests/scripts and iterated, will not iterate through the ResultSet. CLOBs will be handled as if Store As String was selected. BLOBs will be stored as a byte array.

Both CLOBs and BLOBs will be cut off after jdbcsampler.max_retain_result_size bytes. • Count Records - Variables of ResultSet types will be iterated through showing the count of records as result.

Variables will be stored as Strings. For BLOBs the size of the object will be stored. This sampler lets you control a java class that implements the org.apache.jmeter.protocol.java.sampler.JavaSamplerClient interface. By writing your own implementation of this interface, you can use JMeter to harness multiple threads, input parameter control, and data collection. The pull-down menu provides the list of all such implementations found by JMeter in its classpath.

The parameters can then be specified in the table below - as defined by your implementation. Two simple examples ( JavaTest and SleepTest) are provided. The JavaTest example sampler can be useful for checking test plans, because it allows one to set values in almost all the fields.

These can then be used by Assertions, etc. The fields allow variables to be used, so the values of these can readily be seen. Screenshot of Control-Panel of LDAP Request There are two ways to create test cases for testing an LDAP Server. • Inbuilt Test cases.

• User defined Test cases. There are four test scenarios of testing LDAP. The tests are given below: • Add Test • Inbuilt test: This will add a pre-defined entry in the LDAP Server and calculate the execution time. After execution of the test, the created entry will be deleted from the LDAP Server. • User defined test: This will add the entry in the LDAP Server.

User has to enter all the attributes in the table.The entries are collected from the table to add. The execution time is calculated.

The created entry will not be deleted after the test. • Modify Test • Inbuilt test: This will create a pre-defined entry first, then will modify the created entry in the LDAP Server.And calculate the execution time. After execution of the test, the created entry will be deleted from the LDAP Server. • User defined test: This will modify the entry in the LDAP Server. User has to enter all the attributes in the table. The entries are collected from the table to modify. The execution time is calculated.

The entry will not be deleted from the LDAP Server. • Search Test • Inbuilt test: This will create the entry first, then will search if the attributes are available.

It calculates the execution time of the search query. At the end of the execution,created entry will be deleted from the LDAP Server.

• User defined test: This will search the user defined entry(Search filter) in the Search base (again, defined by the user). The entries should be available in the LDAP Server. The execution time is calculated. • Delete Test • Inbuilt test: This will create a pre-defined entry first, then it will be deleted from the LDAP Server. The execution time is calculated. • User defined test: This will delete the user-defined entry in the LDAP Server. The entries should be available in the LDAP Server.

The execution time is calculated. Screenshot of Control-Panel of LDAP Extended Request There are nine test operations defined. These operations are given below: Thread bind Any LDAP request is part of an LDAP session, so the first thing that should be done is starting a session to the LDAP server. For starting this session a thread bind is used, which is equal to the LDAP ' bind' operation. The user is requested to give a username (Distinguished name) and password, which will be used to initiate a session. When no password, or the wrong password is specified, an anonymous session is started. Take care, omitting the password will not fail this test, a wrong password will.

This is stored unencrypted in the test plan). AccessLogSampler was designed to read access logs and generate http requests. For those not familiar with the access log, it is the log the webserver maintains of every request it accepted. This means every image, CSS file, JavaScript file, html file, The current implementation is complete, but some features have not been enabled. There is a filter for the access log parser, but I haven't figured out how to link to the pre-processor.

Once I do, changes to the sampler will be made to enable that functionality. Tomcat uses the common format for access logs. This means any webserver that uses the common log format can use the AccessLogSampler. Server that use common log format include: Tomcat, Resin, Weblogic, and SunOne.

Common log format looks like this: 127.0.0.1 - - [21/Oct/2003:05:37:21 -0500] 'GET /index.jsp?%2Findex.jsp= HTTP/1.1' 200 8343. For the future, it might be nice to filter out entries that do not have a response code of 200. Extending the sampler should be fairly simple.

There are two interfaces you have to implement: • org.apache.jmeter.protocol.http.util.accesslog.LogParser • org.apache.jmeter.protocol.http.util.accesslog.Generator The current implementation of AccessLogSampler uses the generator to create a new HTTPSampler. The servername, port and get images are set by AccessLogSampler. Next, the parser is called with integer 1, telling it to parse one entry. After that, HTTPSampler.sample() is called to make the request. Samp = (HTTPSampler) GENERATOR.generateRequest(); samp.setDomain(this.getDomain()); samp.setPort(this.getPort()); samp.setImageParser(this.isImageParser()); PARSER.parse(1); res = samp.sample(); res.setSampleLabel(samp.toString()); The required methods in LogParser are: • setGenerator(Generator) • parse(int) Classes implementing Generator interface should provide concrete implementation for all the methods. For an example of how to implement either interface, refer to StandardGenerator and TCLogParser.

Yes The TCLogParser processes the access log independently for each thread. The SharedTCLogParser and OrderPreservingLogParser share access to the file, i.e. Each thread gets the next entry in the log. The SessionFilter is intended to handle Cookies across threads. It does not filter out any entries, but modifies the cookie manager so that the cookies for a given IP are processed by a single thread at a time. If two threads try to process samples from the same client IP address, then one will be forced to wait until the other has completed. The LogFilter is intended to allow access log entries to be filtered by filename and regex, as well as allowing for the replacement of file extensions.

However, it is not currently possible to configure this via the GUI, so it cannot really be used. JMeter processes function and variable references before passing the script field to the interpreter, so the references will only be resolved once. Variable and function references in script files will be passed verbatim to the interpreter, which is likely to cause a syntax error. In order to use runtime variables, please use the appropriate props methods, e.g.

Props.get('START.HMS'); props.put('PROP1','1234'); BeanShell does not currently support Java 5 syntax such as generics and the enhanced for loop. Before invoking the script, some variables are set up.

Note that these are BSF variables - i.e. They can be used directly in the script. • log - the • Label - the Sampler label • FileName - the file name, if any • Parameters - text from the Parameters field • args - the parameters, split as described above • SampleResult - pointer to the current • sampler - - pointer to current Sampler • ctx - • vars - - e.g. Vars.get('VAR1'); vars.put('VAR2','value'); vars.remove('VAR3'); vars.putObject('OBJ1',new Object()); • props - JMeterProperties (class ) - e.g. Props.get('START.HMS'); props.put('PROP1','1234'); • OUT - System.out - e.g. OUT.println('message') The ResponseData is set from the return value of the script. If the script returns null, it can set the response directly, by using the method SampleResult.setResponseData(data), where data is either a String or a byte array.

The data type defaults to ' text', but can be set to binary by using the method SampleResult.setDataType(SampleResult.BINARY). The SampleResult variable gives the script full access to all the fields and methods in the SampleResult.

For example, the script has access to the methods setStopThread(boolean) and setStopTest(boolean). Unlike the BeanShell Sampler, the BSF Sampler does not set the ResponseCode, ResponseMessage and sample status via script variables. Currently the only way to change these is via the methods: • SampleResult.setSuccessful(true/false) • SampleResult.setResponseCode('code') • SampleResult.setResponseMessage('message').

Yes (unless script file is provided) If a script file is supplied, that will be used, otherwise the script will be used. Before invoking the script, some variables are set up. Note that these are JSR223 variables - i.e.

They can be used directly in the script. • log - the • Label - the Sampler label • FileName - the file name, if any • Parameters - text from the Parameters field • args - the parameters, split as described above • SampleResult - pointer to the current • sampler - () - pointer to current Sampler • ctx - • vars - - e.g. Vars.get('VAR1'); vars.put('VAR2','value'); vars.remove('VAR3'); vars.putObject('OBJ1',new Object()); • props - JMeterProperties (class ) - e.g. Props.get('START.HMS'); props.put('PROP1','1234'); • OUT - System.out - e.g. OUT.println('message') The ResponseData is set from the return value of the script.

If the script returns null, it can set the response directly, by using the method SampleResult.setResponseData(data), where data is either a String or a byte array. The data type defaults to ' text', but can be set to binary by using the method SampleResult.setDataType(SampleResult.BINARY).

The SampleResult variable gives the script full access to all the fields and methods in the SampleResult. For example, the script has access to the methods setStopThread(boolean) and setStopTest(boolean). Unlike the BeanShell Sampler, the JSR223 Sampler does not set the ResponseCode, ResponseMessage and sample status via script variables. Currently the only way to changes these is via the methods: • SampleResult.setSuccessful(true/false) • SampleResult.setResponseCode('code') • SampleResult.setResponseMessage('message').

The TCP Sampler opens a TCP/IP connection to the specified server. It then sends the text, and waits for a response. If ' Re-use connection' is selected, connections are shared between Samplers in the same thread, provided that the exact same host name string and port are used. Different hosts/port combinations will use different connections, as will different threads. If both of ' Re-use connection' and ' Close connection' are selected, the socket will be closed after running the sampler. On the next sampler, another socket will be created.

You may want to close a socket at the end of each thread loop. If an error is detected - or ' Re-use connection' is not selected - the socket is closed. Another socket will be reopened on the next sample. The following properties can be used to control its operation: tcp.status.prefix text that precedes a status number tcp.status.suffix text that follows a status number tcp.status.properties name of property file to convert status codes to messages tcp.handler Name of TCP Handler class (default TCPClientImpl) - only used if not specified on the GUI The class that handles the connection is defined by the GUI, failing that the property tcp.handler. If not found, the class is then searched for in the package org.apache.jmeter.protocol.tcp.sampler. Users can provide their own implementation. The class must extend org.apache.jmeter.protocol.tcp.sampler.TCPClient.

The following implementations are currently provided. • TCPClientImpl • BinaryTCPClientImpl • LengthPrefixedBinaryTCPClientImpl The implementations behave as follows: TCPClientImpl This implementation is fairly basic. When reading the response, it reads until the end of line byte, if this is defined by setting the property tcp.eolByte, otherwise until the end of the input stream. You can control charset encoding by setting tcp.charset, which will default to Platform default encoding. BinaryTCPClientImpl This implementation converts the GUI input, which must be a hex-encoded string, into binary, and performs the reverse when reading the response. When reading the response, it reads until the end of message byte, if this is defined by setting the property tcp.BinaryTCPClient.eomByte, otherwise until the end of the input stream.

LengthPrefixedBinaryTCPClientImpl This implementation extends BinaryTCPClientImpl by prefixing the binary message data with a binary length byte. The length prefix defaults to 2 bytes. This can be changed by setting the property tcp.binarylength.prefix.length. Timeout handling If the timeout is set, the read will be terminated when this expires. So if you are using an eolByte/ eomByte, make sure the timeout is sufficiently long, otherwise the read will be terminated early. Response handling If tcp.status.prefix is defined, then the response message is searched for the text following that up to the suffix.

If any such text is found, it is used to set the response code. The response message is then fetched from the properties file (if provided). Which client implementation to use. Both of them create connections which can read messages.

However they use a different strategy, as described below: MessageConsumer.receive() calls receive() for every requested message. Retains the connection between samples, but does not fetch messages unless the sampler is active. This is best suited to Queue subscriptions. MessageListener.onMessage() establishes a Listener that stores all incoming messages on a queue. The listener remains active after the sampler completes. This is best suited to Topic subscriptions.

This sampler sends and optionally receives JMS Messages through point-to-point connections (queues). It is different from pub/sub messages and is generally used for handling transactions.

Request Only will typically be used to put load on a JMS System. Request Response will be used when you want to test response time of a JMS service that processes messages sent to the Request Queue as this mode will wait for the response on the Reply queue sent by this service. JMeter use the properties java.naming.security.[principal credentials] - if present - when creating the Queue Connection. If this behaviour is not desired, set the JMeter property JMSSampler.useSecurity.properties=false. The Communication style can be Request Only (also known as Fire and Forget) or Request Response: Request Only will only send messages and will not monitor replies.

As such it can be used to put load on a system. Request Response will send messages and monitor the replies it receives. Behaviour depends on the value of the JNDI Name Reply Queue. If JNDI Name Reply Queue has a value, this queue is used to monitor the results. Matching of request and reply is done with the message id of the request and the correlation id of the reply. If the JNDI Name Reply Queue is empty, then temporary queues will be used for the communication between the requestor and the server. This is very different from the fixed reply queue.

With temporary queues the sending thread will block until the reply message has been received. With Request Response mode, you need to have a Server that listens to messages sent to Request Queue and sends replies to queue referenced by message.getJMSReplyTo(). These check-boxes select the fields which will be used for matching the response message with the original request. Use Request Message Id if selected, the request JMSMessageID will be used, otherwise the request JMSCorrelationID will be used. In the latter case the correlation id must be specified in the request.

Use Response Message Id if selected, the response JMSMessageID will be used, otherwise the response JMSCorrelationID will be used. There are two frequently used JMS Correlation patterns: JMS Correlation ID Pattern i.e.

Match request and response on their correlation Ids =>deselect both checkboxes, and provide a correlation id. JMS Message ID Pattern i.e. Match request message id with response correlation id =>select 'Use Request Message Id' only. In both cases the JMS application is responsible for populating the correlation ID as necessary.

The current implementation supports standard JUnit convention and extensions. It also includes extensions like oneTimeSetUp and oneTimeTearDown. The sampler works like the with some differences. • rather than use JMeter's test interface, it scans the jar files for classes extending JUnit's TestCase class.

That includes any class or subclass. • JUnit test jar files should be placed in jmeter/lib/junit instead of /lib directory. You can also use the ' user.classpath' property to specify where to look for TestCase classes. • JUnit sampler does not use name/value pairs for configuration like the. The sampler assumes setUp and tearDown will configure the test correctly. • The sampler measures the elapsed time only for the test method and does not include setUp and tearDown. • Each time the test method is called, JMeter will pass the result to the listeners.

• Support for oneTimeSetUp and oneTimeTearDown is done as a method. Since JMeter is multi-threaded, we cannot call oneTimeSetUp/ oneTimeTearDown the same way Maven does it. • The sampler reports unexpected exceptions as errors.

There are some important differences between standard JUnit test runners and JMeter's implementation. Rather than make a new instance of the class for each test, JMeter creates 1 instance per sampler and reuses it.

This can be changed with checkbox ' Create a new instance per sample'. The current implementation of the sampler will try to create an instance using the string constructor first. If the test class does not declare a string constructor, the sampler will look for an empty constructor. Example below. General Guidelines If you use setUp and tearDown, make sure the methods are declared public. If you do not, the test may not run properly.

Here are some general guidelines for writing JUnit tests so they work well with JMeter. Since JMeter runs multi-threaded, it is important to keep certain things in mind. • Write the setUp and tearDown methods so they are thread safe. This generally means avoid using static members. • Make the test methods discrete units of work and not long sequences of actions. By keeping the test method to a discrete operation, it makes it easier to combine test methods to create new test plans.

• Avoid making test methods depend on each other. Since JMeter allows arbitrary sequencing of test methods, the runtime behavior is different than the default JUnit behavior. • If a test method is configurable, be careful about where the properties are stored.

Reading the properties from the Jar file is recommended. • Each sampler creates an instance of the test class, so write your test so the setup happens in oneTimeSetUp and oneTimeTearDown. Messages are stored as subsamples of the main sampler. Multipart message parts are stored as subsamples of the message. Special handling for ' file' protocol: The file JavaMail provider can be used to read raw messages from files.

The server field is used to specify the path to the parent of the folder. Individual message files should be stored with the name n.msg, where n is the message number.

Alternatively, the server field can be the name of a file which contains a single message. The current implementation is quite basic, and is mainly intended for debugging purposes. The Test Action sampler is a sampler that is intended for use in a conditional controller.

Rather than generate a sample, the test element either pauses or stops the selected target. This sampler can also be useful in conjunction with the Transaction Controller, as it allows pauses to be included without needing to generate a sample. For variable delays, set the pause time to zero, and add a Timer as a child. The ' Stop' action stops the thread or test after completing any samples that are in progress.

The ' Stop Now' action stops the test without waiting for samples to complete; it will interrupt any active samples. If some threads fail to stop within the 5 second time-limit, a message will be displayed in GUI mode. You can try using the Stop command to see if this will stop the threads, but if not, you should exit JMeter. In non-GUI mode, JMeter will exit if some threads fail to stop within the 5 second time limit. The SMTP Sampler can send mail messages using SMTP/SMTPS protocol.

It is possible to set security protocols for the connection (SSL and TLS), as well as user authentication. If a security protocol is used a verification on the server certificate will occur. Two alternatives to handle this verification are available: Trust all certificates This will ignore certificate chain verification Use a local truststore With this option the certificate chain will be validated against the local truststore file.

The OS Process Sampler is a sampler that can be used to execute commands on the local machine. It should allow execution of any command that can be run from the command line. Validation of the return code can be enabled, and the expected return code can be specified.

Note that OS shells generally provide command-line parsing. This varies between OSes, but generally the shell will split parameters on white-space. Some shells expand wild-card file names; some don't. The quoting mechanism also varies between OSes. The sampler deliberately does not do any parsing or quote handling.

The command and its parameters must be provided in the form expected by the executable. This means that the sampler settings will not be portable between OSes. Many OSes have some built-in commands which are not provided as separate executables. For example the Windows DIR command is part of the command interpreter ( CMD.EXE). These built-ins cannot be run as independent programs, but have to be provided as arguments to the appropriate command interpreter. For example, the Windows command-line: DIR C: TEMP needs to be specified as follows: Command: CMD Param 1: /C Param 2: DIR Param 3: C: TEMP. Using the Simple Controller this example (see Figure 6).

In this example, we created a Test Plan that sends two Ant HTTP requests and two Log4J HTTP requests. We grouped the Ant and Log4J requests by placing them inside Simple Logic Controllers.

Remember, the Simple Logic Controller has no effect on how JMeter processes the controller(s) you add to it. So, in this example, JMeter sends the requests in the following order: Ant Home Page, Ant News Page, Log4J Home Page, Log4J History Page. Note, the File Reporter is configured to store the results in a file named ' simple-test.dat' in the current directory. Figure 6 Simple Controller Example. Looping Example this example (see Figure 4). In this example, we created a Test Plan that sends a particular HTTP Request only once and sends another HTTP Request five times.

Figure 4 - Loop Controller Example We configured the Thread Group for a single thread and a loop count value of one. Instead of letting the Thread Group control the looping, we used a Loop Controller. You can see that we added one HTTP Request to the Thread Group and another HTTP Request to a Loop Controller. We configured the Loop Controller with a loop count value of five. JMeter will send the requests in the following order: Home Page, News Page, News Page, News Page, News Page, and News Page. The Once Only Logic Controller tells JMeter to process the controller(s) inside it only once per Thread, and pass over any requests under it during further iterations through the test plan.

The Once Only Controller will now execute always during the first iteration of any looping parent controller. Thus, if the Once Only Controller is placed under a Loop Controller specified to loop 5 times, then the Once Only Controller will execute only on the first iteration through the Loop Controller (i.e. Every 5 times).

Note this means the Once Only Controller will still behave as previously expected if put under a Thread Group (runs only once per test per Thread), but now the user has more flexibility in the use of the Once Only Controller. For testing that requires a login, consider placing the login request in this controller since each thread only needs to login once to establish a session. Once Only Example this example (see Figure 5). In this example, we created a Test Plan that has two threads that send HTTP request. Each thread sends one request to the Home Page, followed by three requests to the Bug Page. Although we configured the Thread Group to iterate three times, each JMeter thread only sends one request to the Home Page because this request lives inside a Once Only Controller.

Once Only Controller Example Each JMeter thread will send the requests in the following order: Home Page, Bug Page, Bug Page, Bug Page. Note, the File Reporter is configured to store the results in a file named ' loop-test.dat' in the current directory. Simple Interleave Example this example (see Figure 1).

In this example, we configured the Thread Group to have two threads and a loop count of five, for a total of ten requests per thread. See the table below for the sequence JMeter sends the HTTP Requests.

Figure 1 - Interleave Controller Example 1 Loop Iteration Each JMeter Thread Sends These HTTP Requests 1 News Page 1 Log Page 2 FAQ Page 2 Log Page 3 Gump Page 3 Log Page 4 Because there are no more requests in the controller, JMeter starts over and sends the first HTTP Request, which is the News Page. 4 Log Page 5 FAQ Page 5 Log Page. Useful Interleave Example another example (see Figure 2). In this example, we configured the Thread Group to have a single thread and a loop count of eight.

Notice that the Test Plan has an outer Interleave Controller with two Interleave Controllers inside of it. Figure 2 - Interleave Controller Example 2 The outer Interleave Controller alternates between the two inner ones.

Then, each inner Interleave Controller alternates between each of the HTTP Requests. Each JMeter thread will send the requests in the following order: Home Page, Interleaved, Bug Page, Interleaved, CVS Page, Interleaved, and FAQ Page, Interleaved. Note, the File Reporter is configured to store the results in a file named ' interleave-test2.dat' in the current directory.

Figure 3 - Interleave Controller Example 3 If the two interleave controllers under the main interleave controller were instead simple controllers, then the order would be: Home Page, CVS Page, Interleaved, Bug Page, FAQ Page, Interleaved. However, if ' ignore sub-controller blocks' was checked on the main interleave controller, then the order would be: Home Page, Interleaved, Bug Page, Interleaved, CVS Page, Interleaved, and FAQ Page, Interleaved. If the switch value is out of range, it will run the zeroth element, which therefore acts as the default for the numeric case. It also runs the zeroth element if the value is the empty string.

If the value is non-numeric (and non-empty), then the Switch Controller looks for the element with the same name (case is significant). If none of the names match, then the element named ' default' (case not significant) is selected. If there is no default, then no element is selected, and the controller will not run anything. ForEach Example this example (see Figure 7). In this example, we created a Test Plan that sends a particular HTTP Request only once and sends another HTTP Request to every link that can be found on the page.

Figure 7 - ForEach Controller Example We configured the Thread Group for a single thread and a loop count value of one. You can see that we added one HTTP Request to the Thread Group and another HTTP Request to the ForEach Controller.

After the first HTTP request, a regular expression extractor is added, which extracts all the html links out of the return page and puts them in the inputVar variable In the ForEach loop, a HTTP sampler is added which requests all the links that were extracted from the first returned HTML page. ForEach Example Here is you can download. This has two Regular Expressions and ForEach Controllers. The first RE matches, but the second does not match, so no samples are run by the second ForEach Controller Figure 8 - ForEach Controller Example 2 The Thread Group has a single thread and a loop count of two.

Sample 1 uses the JavaTest Sampler to return the string ' a b c d'. The Regex Extractor uses the expression ( w) s which matches a letter followed by a space, and returns the letter (not the space). Any matches are prefixed with the string ' inputVar'. The ForEach Controller extracts all variables with the prefix ' inputVar_', and executes its sample, passing the value in the variable ' returnVar'. In this case it will set the variable to the values ' a' ' b' and ' c' in turn. The For 1 Sampler is another Java Sampler which uses the return variable ' returnVar' as part of the sample Label and as the sampler Data.

Sample 2, Regex 2 and For 2 are almost identical, except that the Regex has been changed to ' ( w) sx', which clearly won't match. Thus the For 2 Sampler will not be run. The Module Controller provides a mechanism for substituting test plan fragments into the current test plan at run-time. A test plan fragment consists of a Controller and all the test elements (samplers etc.) contained in it.

The fragment can be located in any Thread Group, or on the. If the fragment is located in a Thread Group, then its Controller can be disabled to prevent the fragment being run except by the Module Controller. Or you can store the fragments in a dummy Thread Group, and disable the entire Thread Group.

There can be multiple fragments, each with a different series of samplers under them. The module controller can then be used to easily switch between these multiple test cases simply by choosing the appropriate controller in its drop down box. This provides convenience for running many alternate test plans quickly and easily. A fragment name is made up of the Controller name and all its parent names. For example: Test Plan / Protocol: JDBC / Control / Interleave Controller (Module1) Any fragments used by the Module Controller must have a unique name, as the name is used to find the target controller when a test plan is reloaded. For this reason it is best to ensure that the Controller name is changed from the default - as shown in the example above - otherwise a duplicate may be accidentally created when new elements are added to the test plan. The include controller is designed to use an external JMX file.

To use it, create a Test Fragment underneath the Test Plan and add any desired samplers, controllers etc. Then save the Test Plan. The file is now ready to be included as part of other Test Plans. For convenience, a can also be added in the external JMX file for debugging purposes. A can be used to reference the Test Fragment. The will be ignored during the include process. If the test uses a Cookie Manager or User Defined Variables, these should be placed in the top-level test plan, not the included file, otherwise they are not guaranteed to work.

There are two modes of operation: • additional sample is added after the nested samples • additional sample is added as a parent of the nested samples The generated sample time includes all the times for the nested samplers excluding by default (since 2.11) timers and processing time of pre/post processors unless checkbox ' Include duration of timer and pre-post processors in generated sample' is checked. Depending on the clock resolution, it may be slightly longer than the sum of the individual samplers plus timers. The clock might tick after the controller recorded the start time but before the first sample starts. Similarly at the end. The generated sample is only regarded as successful if all its sub-samples are successful.

In parent mode, the individual samples can still be seen in the Tree View Listener, but no longer appear as separate entries in other Listeners. Also, the sub-samples do not appear in CSV log files, but they can be saved to XML files.

Most of the listeners perform several roles in addition to 'listening' to the test results. They also provide means to view, save, and read saved test results. Note that Listeners are processed at the end of the scope in which they are found. The saving and reading of test results is generic. The various listeners have a panel whereby one can specify the file to which the results will be written (or read from). By default, the results are stored as XML files, typically with a '.jtl' extension. Storing as CSV is the most efficient option, but is less detailed than XML (the other available option).

Listeners do not process sample data in non-GUI mode, but the raw data will be saved if an output file has been configured. In order to analyse the data generated by a non-GUI test run, you need to load the file into the appropriate Listener. Listeners can use a lot of memory if there are a lot of samples.

Most of the listeners currently keep a copy of every sample in their scope, apart from: • Simple Data Writer • BeanShell/JSR223 Listener • Mailer Visualizer • Summary Report The following Listeners no longer need to keep copies of every single sample. Instead, samples with the same elapsed time are aggregated. Less memory is now needed, especially if most samples only take a second or two at most. • Aggregate Report • Aggregate Graph To minimise the amount of memory needed, use the Simple Data Writer, and use the CSV format. Name of the file containing sample results.

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). JMeter 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. The Graph Results listener generates a simple graph that plots all sample times. Along the bottom of the graph, the current sample (black), the current average of all samples (blue), the current standard deviation (red), and the current throughput rate (green) are displayed in milliseconds. The throughput number represents the actual number of requests/minute the server handled.

This calculation includes any delays you added to your test and JMeter's own internal processing time. The advantage of doing the calculation like this is that this number represents something real - your server in fact handled that many requests per minute, and you can increase the number of threads and/or decrease the delays to discover your server's maximum throughput. Whereas if you made calculations that factored out delays and JMeter's processing, it would be unclear what you could conclude from that number. Screenshot of Control-Panel of Graph Results The following table briefly describes the items on the graph. Further details on the precise meaning of the statistical terms can be found on the web - e.g. Wikipedia - or by consulting a book on statistics. • Data - plot the actual data values • Average - plot the Average • Median - plot the (midway value) • Deviation - plot the (a measure of the variation) • Throughput - plot the number of samples per unit of time The individual figures at the bottom of the display are the current values.

' Latest Sample' is the current elapsed sample time, shown on the graph as ' Data'. The value displayed on the top left of graph is the max of 90 th percentile of response time. The View Results Tree shows a tree of all sample responses, allowing you to view the response for any sample. In addition to showing the response, you can see the time it took to get this response, and some response codes. Note that the Request panel only shows the headers added by JMeter. It does not show any headers (such as Host) that may be added by the HTTP protocol implementation. There are several ways to view the response, selectable by a drop-down box at the bottom of the left hand panel.

Renderer Description CSS/JQuery Tester The CSS/JQuery Tester only works for text responses. It shows the plain text in the upper panel. The ' Test' button allows the user to apply the CSS/JQuery to the upper panel and the results will be displayed in the lower panel. The CSS/JQuery expression engine can be JSoup or Jodd, syntax of these 2 implementation differs slightly. If the document is larger than 10 MB, then it won't be displayed.

To change this limit, set the JMeter property document.max_size (unit is byte) or set to 0 to remove the limit. HTML The HTML view attempts to render the response as HTML. The rendered HTML is likely to compare poorly to the view one would get in any web browser; however, it does provide a quick approximation that is helpful for initial result evaluation. Images, style-sheets, etc. Aren't downloaded.

HTML (download resources) If the HTML (download resources) view option is selected, the renderer may download images, style-sheets, etc. Referenced by the HTML code. HTML Source formatted If the HTML Source formatted view option is selected, the renderer will display the HTML source code formatted and cleaned.

JSON The JSON view will show the response in tree style (also handles JSON embedded in JavaScript). JSON Path Tester The JSON Path Tester view will let you test your JSON-PATH expressions and see the extracted data from a particular response. Regexp Tester The Regexp Tester view only works for text responses.

It shows the plain text in the upper panel. The ' Test' button allows the user to apply the Regular Expression to the upper panel and the results will be displayed in the lower panel.

The regular expression engine is the same as that used in the Regular Expression Extractor. For example, the RE (JMeter w*).* applied to the current JMeter home page gives the following output: Match count: 26 Match[1][0]=JMeter - Apache JMeter Match[1][1]=JMeter Match[2][0]=JMeter' title='JMeter' border='0'/>Match[2][1]=JMeter Match[3][0]=JMeterCommitters'>Contributors Match[3][1]=JMeterCommitters and so on The first number in [] is the match number; the second number is the group. Group [0] is whatever matched the whole RE. Group [1] is whatever matched the 1 st group, i.e.

(JMeter w*) in this case. See Figure 9b (below). Text The default Text view shows all of the text contained in the response. Note that this will only work if the response content-type is considered to be text. If the content-type begins with any of the following, it is considered as binary, otherwise it is considered to be text.

Image/ audio/ video/ XML The XML view will show response in tree style. Any DTD nodes or Prolog nodes will not show up in tree; however, response may contain those nodes. XPath Tester The XPath Tester only works for text responses. It shows the plain text in the upper panel. The ' Test' button allows the user to apply the XPath query to the upper panel and the results will be displayed in the lower panel. Scroll automatically?

Option permit to have last node display in tree selection. With Search option, most of the views also allow the displayed data to be searched; the result of the search will be high-lighted in the display above. For example the Control panel screenshot below shows one result of searching for ' Java'. Note that the search operates on the visible text, so you may get different results when searching the Text and HTML views. Note: The regular expression uses the Java engine (not ORO engine like the Regular Expression Extractor or Regexp Tester view). If there is no content-type provided, then the content will not be displayed in the any of the Response Data panels.

You can use to save the data in this case. Note that the response data will still be available in the sample result, so can still be accessed using Post-Processors. If the response data is larger than 200K, then it won't be displayed. To change this limit, set the JMeter property view.results.tree.max_size. You can also use save the entire response to a file using. Additional renderers can be created.

The class must implement the interface org.apache.jmeter.visualizers.ResultRenderer and/or extend the abstract class org.apache.jmeter.visualizers.SamplerResultTab, and the compiled code must be available to JMeter (e.g. By adding it to the lib/ext directory). The aggregate report creates a table row for each differently named request in your test.

For each request, it totals the response information and provides request count, min, max, average, error rate, approximate throughput (request/second) and Kilobytes per second throughput. Once the test is done, the throughput is the actual through for the duration of the entire test. The throughput is calculated from the point of view of the sampler target (e.g.

The remote server in the case of HTTP samples). JMeter takes into account the total time over which the requests have been generated. If other samplers and timers are in the same thread, these will increase the total time, and therefore reduce the throughput value. So two identical samplers with different names will have half the throughput of two samplers with the same name. It is important to choose the sampler names correctly to get the best results from the Aggregate Report. Calculation of the and 90% Line (90 th ) values requires additional memory.

JMeter now combines samples with the same elapsed time, so far less memory is used. However, for samples that take more than a few seconds, the probability is that fewer samples will have identical times, in which case more memory will be needed. Note you can use this listener afterwards to reload a CSV or XML results file which is the recommended way to avoid performance impacts. See the for a similar Listener that does not store individual samples and so needs constant memory. • Label - The label of the sample. If ' Include group name in label?'

Is selected, then the name of the thread group is added as a prefix. This allows identical labels from different thread groups to be collated separately if required.

• # Samples - The number of samples with the same label • Average - The average time of a set of results • Median - The is the time in the middle of a set of results. 50% of the samples took no more than this time; the remainder took at least as long. • 90% Line - 90% of the samples took no more than this time. The remaining samples took at least as long as this. (90 th ) • 95% Line - 95% of the samples took no more than this time. The remaining samples took at least as long as this.

(95 th ) • 99% Line - 99% of the samples took no more than this time. The remaining samples took at least as long as this. (99 th ) • Min - The shortest time for the samples with the same label • Max - The longest time for the samples with the same label • Error% - Percent of requests with errors • Throughput - the is measured in requests per second/minute/hour. The time unit is chosen so that the displayed rate is at least 1.0. When the throughput is saved to a CSV file, it is expressed in requests/second, i.e.

30.0 requests/minute is saved as 0.5. • Received KB/sec - The throughput measured in received Kilobytes per second • Sent KB/sec - The throughput measured in sent Kilobytes per second Times are in milliseconds. • Columns to display: Choose the column(s) to display in graph. • Rectangles color: Click on right color rectangle open a popup dialog to choose a custom color for column.

• Foreground color Allow to change the value text color. • Value font: Allow to define font settings for the text. • Draw outlines bar? To draw or not the border line on bar chart • Show number grouping? Show or not the number grouping in Y Axis labels. • Value labels vertical? Change orientation for value label.

(Default is horizontal) • Column label selection: Filter by result label. A regular expression can be used, example:.*Transaction.* Before display the graph, click on Apply filter button to refresh internal data. Yes (unless script file is provided) Before invoking the script, some variables are set up in the BeanShell interpreter: • log - () - can be used to write to the log file • ctx - () - gives access to the context • vars - () - gives read/write access to variables: vars.get(key); vars.put(key,val); vars.putObject('OBJ1',new Object()); • props - (JMeterProperties - class ) - e.g. Props.get('START.HMS'); props.put('PROP1','1234'); • sampleResult, prev - () - gives access to the previous • sampleEvent () gives access to the current sample event For details of all the methods available on each of the above variables, please check the Javadoc If the property beanshell.listener.init is defined, this is used to load an initialisation file, which can be used to define methods etc. For use in the BeanShell script. The summary report creates a table row for each differently named request in your test. This is similar to the, except that it uses less memory.

The throughput is calculated from the point of view of the sampler target (e.g. The remote server in the case of HTTP samples). JMeter takes into account the total time over which the requests have been generated. If other samplers and timers are in the same thread, these will increase the total time, and therefore reduce the throughput value. So two identical samplers with different names will have half the throughput of two samplers with the same name. It is important to choose the sampler labels correctly to get the best results from the Report. • Label - The label of the sample.

If ' Include group name in label?' Is selected, then the name of the thread group is added as a prefix. This allows identical labels from different thread groups to be collated separately if required. • # Samples - The number of samples with the same label • Average - The average elapsed time of a set of results • Min - The lowest elapsed time for the samples with the same label • Max - The longest elapsed time for the samples with the same label • Std. - the of the sample elapsed time • Error% - Percent of requests with errors • Throughput - the is measured in requests per second/minute/hour. The time unit is chosen so that the displayed rate is at least 1.0.

When the throughput is saved to a CSV file, it is expressed in requests/second, i.e. 30.0 requests/minute is saved as 0.5. • Received KB/sec - The throughput measured in Kilobytes per second • Sent KB/sec - The throughput measured in Kilobytes per second • Avg. Bytes - average size of the sample response in bytes. Times are in milliseconds.

This test element can be placed anywhere in the test plan. For each sample in its scope, it will create a file of the response Data. The primary use for this is in creating functional tests, but it can also be useful where the response is too large to be displayed in the Listener.

The file name is created from the specified prefix, plus a number (unless this is disabled, see below). The file extension is created from the document type, if known. If not known, the file extension is set to ' unknown'. If numbering is disabled, and adding a suffix is disabled, then the file prefix is taken as the entire file name. This allows a fixed file name to be generated if required. The generated file name is stored in the sample response, and can be saved in the test log output file if required. The current sample is saved first, followed by any sub-samples (child samples).

If a variable name is provided, then the names of the files are saved in the order that the sub-samples appear. Yes (unless script file is provided) The script (or file) is processed using the BSFEngine.exec() method, which does not return a value. Before invoking the script, some variables are set up. Note that these are BSF variables - i.e.

They can be used directly in the script. Log () - can be used to write to the log file Label the String Label FileName the script file name (if any) Parameters the parameters (as a String) args the parameters as a String array (split on whitespace) ctx () - gives access to the context vars () - gives read/write access to variables: vars.get(key); vars.put(key,val); vars.putObject('OBJ1',new Object()); vars.getObject('OBJ2'); props (JMeterProperties - class ) - e.g. Props.get('START.HMS'); props.put('PROP1','1234'); sampleResult, prev () - gives access to the SampleResult sampleEvent () - gives access to the SampleEvent sampler ()- gives access to the last sampler OUT System.out - e.g. OUT.println('message') For details of all the methods available on each of the above variables, please check the Javadoc. Yes (unless script file is provided) Before invoking the script, some variables are set up.

Note that these are JSR223 variables - i.e. They can be used directly in the script. Log () - can be used to write to the log file Label the String Label FileName the script file name (if any) Parameters the parameters (as a String) args the parameters as a String array (split on whitespace) ctx () - gives access to the context vars () - gives read/write access to variables: vars.get(key); vars.put(key,val); vars.putObject('OBJ1',new Object()); vars.getObject('OBJ2'); props (JMeterProperties - class ) - e.g.

Props.get('START.HMS'); props.put('PROP1','1234'); sampleResult, prev () - gives access to the SampleResult sampleEvent () - gives access to the SampleEvent sampler ()- gives access to the last sampler OUT System.out - e.g. OUT.println('message') For details of all the methods available on each of the above variables, please check the Javadoc. This test element can be placed anywhere in the test plan. Generates a summary of the test run so far to the log file and/or standard output. Both running and differential totals are shown. Output is generated every n seconds (default 30 seconds) on the appropriate time boundary, so that multiple test runs on the same time will be synchronised. See jmeter.properties file for the summariser configuration items: # Define the following property to automatically start a summariser with that name # (applies to non-GUI mode only) #summariser.name=summary # # interval between summaries (in seconds) default 3 minutes #summariser.interval=30 # # Write messages to log file #summariser. Hex File For Star Satan. log=true # # Write messages to System.out #summariser.out=true This element is mainly intended for batch (non-GUI) runs.

As a special case, the string ' t' (without quotes) in the delimiter field is treated as a Tab. When the end of file ( EOF) is reached, and the recycle option is true, reading starts again with the first line of the file. If the recycle option is false, and stopThread is false, then all the variables are set to when the end of file is reached. This value can be changed by setting the JMeter property csvdataset.eofstring. If the Recycle option is false, and Stop Thread is true, then reaching EOF will cause the thread to be stopped. Name of the file to be read.

Relative file names are resolved with respect to the path of the active test plan. For distributed testing, the CSV file must be stored on the server host system in the correct relative directory to where the JMeter server is started. Absolute file names are also supported, but note that they are unlikely to work in remote mode, unless the remote server has the same directory structure. If the same physical file is referenced in two different ways - e.g. Csvdata.txt and./csvdata.txt - then these are treated as different files.

If the OS does not distinguish between upper and lower case, csvData.TXT would also be opened separately. • All threads - (the default) the file is shared between all the threads. • Current thread group - each file is opened once for each thread group in which the element appears • Current thread - each file is opened separately for each thread • Identifier - all threads sharing the same identifier share the same file. So for example if you have 4 thread groups, you could use a common id for two or more of the groups to share the file between them. Or you could use the thread number to share the file between the same thread numbers in different thread groups. The DNS Cache Manager element allows to test applications, which have several servers behind load balancers (CDN, etc.), when user receives content from different IP's.

By default JMeter uses JVM DNS cache. That's why only one server from the cluster receives load. DNS Cache Manager resolves names for each thread separately each iteration and saves results of resolving to its internal DNS Cache, which is independent from both JVM and OS DNS caches. A mapping for static hosts can be used to simulate something like /etc/hosts file. These entries will be preferred over the custom resolver. Use custom DNS resolver has to be enabled, if you want to use this mapping. Usage of static host table Say, you have a test server, that you want to reach with a name, that is not (yet) set up in your DNS servers.

For our example, this would be www.example.com for the server name, which you want to reach at the IP of the server a123.another.example.org. You could change your workstation and add an entry to your /etc/hosts file - or the equivalent for your OS, or add an entry to the Static Host Table of the DNS Cache Manager. You would type www.example.com into the first column ( Host) and a123.another.example.org into the second column ( Hostname or IP address). As the name of the second column implies, you could even use the IP address of your test server there.

The IP address for the test server will be looked up by using the custom DNS resolver. When none is given, the system DNS resolver will be used. Now you can use www.example.com in your HTTPClient4 samplers and the requests will be made against a123.another.example.org with all headers set to www.example.com.

The Authorization Manager lets you specify one or more user logins for web pages that are restricted using server authentication. You see this type of authentication when you use your browser to access a restricted page, and your browser displays a login dialog box. JMeter transmits the login information when it encounters this type of page. The Authorization headers may not be shown in the Tree View Listener ' Request' tab. The Java implementation does pre-emptive authentication, but it does not return the Authorization header when JMeter fetches the headers. The HttpComponents (HC 4.5.X) implementation defaults to pre-emptive since 3.2 and the header will be shown.

To disable this, set the values as below, in which case authentication will only be performed in response to a challenge. In the file jmeter.properties set httpclient4.auth.preemptive=false. Kerberos Configuration: To configure Kerberos you need to setup at least two JVM system properties: • -Djava.security.krb5.conf=krb5.conf • -Djava.security.auth.login.config=jaas.conf You can also configure those two properties in the file bin/system.properties. Look at the two sample configuration files ( krb5.conf and jaas.conf) located in the JMeter bin folder for references to more documentation, and tweak them to match your Kerberos configuration.

When generating a SPN for Kerberos SPNEGO authentication IE and Firefox will omit the port number from the URL. Chrome has an option ( --enable-auth-negotiate-port) to include the port number if it differs from the standard ones ( 80 and 443). That behavior can be emulated by setting the following JMeter property as below. In jmeter.properties or user.properties, set: • kerberos.spnego.strip_port=false Controls: • Add Button - Add an entry to the authorization table. • Delete Button - Delete the currently selected table entry. • Load Button - Load a previously saved authorization table and add the entries to the existing authorization table entries. • Save As Button - Save the current authorization table to a file.

Authorization Example this example. In this example, we created a Test Plan on a local server that sends three HTTP requests, two requiring a login and the other is open to everyone. See figure 10 to see the makeup of our Test Plan.

On our server, we have a restricted directory named, ' secret', which contains two files, ' index.html' and ' index2.html'. We created a login id named, ' kevin', which has a password of ' spot'. So, in our Authorization Manager, we created an entry for the restricted directory and a username and password (see figure 11). The two HTTP requests named ' SecretPage1' and ' SecretPage2' make requests to ' /secret/index.html' and ' /secret/index2.html'.

The other HTTP request, named ' NoSecretPage' makes a request to ' /index.html'. Figure 10 - Test Plan Figure 11 - Authorization Manager Control Panel When we run the Test Plan, JMeter looks in the Authorization table for the URL it is requesting. If the Base URL matches the URL, then JMeter passes this information along with the request. The HTTP Cache Manager is used to add caching functionality to HTTP requests within its scope to simulate browser cache feature. Each Virtual User thread has its own Cache. By default, Cache Manager will store up to 5000 items in cache per Virtual User thread, using LRU algorithm.

Use property ' maxSize' to modify this value. Note that the more you increase this value the more HTTP Cache Manager will consume memory, so be sure to adapt the -Xmx JVM option accordingly. If a sample is successful (i.e. Has response code 2xx) then the Last-Modified and Etag (and Expired if relevant) values are saved for the URL. Before executing the next sample, the sampler checks to see if there is an entry in the cache, and if so, the If-Last-Modified and If-None-Match conditional headers are set for the request. Additionally, if the ' Use Cache-Control/Expires header' option is selected, then the Cache-Control/ Expires value is checked against the current time.

If the request is a GET request, and the timestamp is in the future, then the sampler returns immediately, without requesting the URL from the remote server. This is intended to emulate browser behaviour. Note that if Cache-Control header is ' no-cache', the response will be stored in cache as pre-expired, so will generate a conditional GET request. If Cache-Control has any other value, the ' max-age' expiry option is processed to compute entry lifetime, if missing then expire header will be used, if also missing entry will be cached as specified in section 13.2.4. Using Last-Modified time and response Date. A simple query used to determine if the database is still responding. This defaults to the ' isValid()' method of the jdbc driver, which is suitable for many databases.

However some may require a different query; for example Oracle something like ' SELECT 1 FROM DUAL' could be used. The list of the validation queries can be configured with jdbc.config.check.query property and are by default: hsqldb select 1 from INFORMATION_SCHEMA.SYSTEM_USERS Oracle select 1 from dual DB2 select 1 from sysibm.sysdummy1 MySQL select 1 Microsoft SQL Server (MS JDBC driver) select 1 PostgreSQL select 1 Ingres select 1 Derby values 1 H2 select 1 Firebird select 1 from rdb$database. Fully qualified name of driver class. (Must be in JMeter's classpath - easiest to copy.jar file into JMeter's /lib directory). The Keystore Config Element lets you configure how Keystore will be loaded and which keys it will use.

This component is typically used in HTTPS scenarios where you don't want to take into account keystore initialization into account in response time. To use this element, you need to setup first a Java Key Store with the client certificates you want to test, to do that: • Create your certificates either with Java keytool utility or through your PKI • If created by PKI, import your keys in Java Key Store by converting them to a format acceptable by JKS • Then reference the keystore file through the two JVM properties (or add them in system.properties): • -Djavax.net.ssl.keyStore=path_to_keystore • -Djavax.net.ssl.keyStorePassword=password_of_keystore. The Random Variable Config Element is used to generate random numeric strings and store them in variable for use later. It's simpler than using together with the function.

The output variable is constructed by using the random number generator, and then the resulting number is formatted using the format string. The number is calculated using the formula minimum+Random.nextInt(maximum-minimum+1). Random.nextInt() requires a positive integer. This means that maximum-minimum - i.e. The range - must be less than, however the minimum and maximum values can be any long values so long as the range is OK.

Creates a MongoDB connection (used by Sampler) from the supplied Connection settings. Each thread gets its own connection. The connection configuration name is used by the JDBC Sampler to select the appropriate connection. You can then access com.mongodb.DB object in Beanshell or JSR223 Test Elements through the element using this code import com.mongodb.DB; import org.apache.jmeter.protocol.mongodb.config.MongoDBHolder; DB db = MongoDBHolder.getDBFromSource('value of property MongoDB Source', 'value of property Database Name'). Assertions can be applied to either the main sample, the sub-samples or both. The default is to apply the assertion to the main sample only.

If the Assertion supports this option, then there will be an entry on the GUI which looks like the following: Assertion Scope or the following Assertion Scope If a sub-sampler fails and the main sample is successful, then the main sample will be set to failed status and an Assertion Result will be added. If the JMeter variable option is used, it is assumed to relate to the main sample, and any failure will be applied to the main sample only. The response assertion control panel lets you add pattern strings to be compared against various fields of the request or response. The pattern strings are: • Contains, Matches: Perl5-style regular expressions • Equals, Substring: plain text, case-sensitive A summary of the pattern matching characters can be found at You can also choose whether the strings will be expected to match the entire response, or if the response is only expected to contain the pattern. You can attach multiple assertions to any controller for additional flexibility. Note that the pattern string should not include the enclosing delimiters, i.e. Use Price: d+ not /Price: d+/.

By default, the pattern is in multi-line mode, which means that the '.' Meta-character does not match newline. In multi-line mode, ' ^' and ' $' match the start or end of any line anywhere within the string - not just the start and end of the entire string. Note that s does match new-line.

Case is also significant. To override these settings, one can use the extended regular expression syntax. For example: (?i) ignore case (?s) treat target as single line, i.e. Matches new-line (?is) both the above These can be used anywhere within the expression and remain in effect until overridden. (?i)apple(?-i) Pie matches ' ApPLe Pie', but not ' ApPLe pIe' (?s)Apple.+?Pie matches Apple followed by Pie, which may be on a subsequent line. Apple(?s).+?Pie same as above, but it's probably clearer to use the (?s) at the start. Instructs JMeter to set the status to success initially.

The overall success of the sample is determined by combining the result of the assertion with the existing Response status. When the Ignore Status checkbox is selected, the Response status is forced to successful before evaluating the Assertion. HTTP Responses with statuses in the 4xx and 5xx ranges are normally regarded as unsuccessful. The ' Ignore status' checkbox can be used to set the status successful before performing further checks.

Note that this will have the effect of clearing any previous assertion failures, so make sure that this is only set on the first assertion. Indicates how the text being tested is checked against the pattern. • Contains - true if the text contains the regular expression pattern • Matches - true if the whole text matches the regular expression pattern • Equals - true if the whole text equals the pattern string (case-sensitive) • Substring - true if the text contains the pattern string (case-sensitive) Equals and Substring patterns are plain strings, not regular expressions. NOT may also be selected to invert the result of the check. OR Apply each assertion in OR combination (if 1 pattern to test matches, Assertion will be ok) instead of AND (All patterns must match so that Assertion is OK). The BeanShell Assertion allows the user to perform assertion checking using a BeanShell script. For full details on using BeanShell, please see the Note that a different Interpreter is used for each independent occurrence of the assertion in each thread in a test script, but the same Interpreter is used for subsequent invocations.

This means that variables persist across calls to the assertion. All Assertions are called from the same thread as the sampler. If the property ' beanshell.assertion.init' is defined, it is passed to the Interpreter as the name of a sourced file. This can be used to define common methods and variables.

There is a sample init file in the bin directory: BeanShellAssertion.bshrc The test element supports the ThreadListener and TestListener methods. These should be defined in the initialisation file. See the file BeanShellListeners.bshrc for example definitions. Yes (unless script file is provided) There's a you can try. Before invoking the script, some variables are set up in the BeanShell interpreter. These are strings unless otherwise noted: • log - the Object. (e.g.) log.warn('Message'[,Throwable]) • SampleResult - the Object; read-write • Response - the response Object; read-write • Failure - boolean; read-write; used to set the Assertion status • FailureMessage - String; read-write; used to set the Assertion message • ResponseData - the response body (byte []) • ResponseCode - e.g.

200 • ResponseMessage - e.g. OK • ResponseHeaders - contains the HTTP headers • RequestHeaders - contains the HTTP headers sent to the server • SampleLabel • SamplerData - data that was sent to the server • ctx - • vars - - e.g. Vars.get('VAR1'); vars.put('VAR2','value'); vars.putObject('OBJ1',new Object()); • props - JMeterProperties (class ) - e.g. Props.get('START.HMS'); props.put('PROP1','1234'); The following methods of the Response object may be useful: • setStopThread(boolean) • setStopTest(boolean) • String getSampleLabel() • setSampleLabel(String). The XPath Assertion tests a document for well formedness, has the option of validating against a DTD, or putting the document through JTidy and testing for an XPath. If that XPath exists, the Assertion is true. Using ' /' will match any well-formed document, and is the default XPath Expression.

The assertion also supports boolean expressions, such as ' count(//*error)=2'. See for more information on XPath. Some sample expressions: • //title[text()='Text to match'] - matches Text to match anywhere in the response • /title[text()='Text to match'] - matches Text to match at root level in the response. Yes (unless script file is provided) The script (or file) is processed using the BSFEngine.exec() method, which does not return a value. The following variables are set up for use by the script: • log - () - can be used to write to the log file • Label - the String Label • Filename - the script file name (if any) • Parameters - the parameters (as a String) • args - the parameters as a String array (split on whitespace) • ctx - () - gives access to the context • vars - () - gives read/write access to variables: vars.get(key); vars.put(key,val); vars.putObject('OBJ1',new Object()); vars.getObject('OBJ2'); • props - (JMeterProperties - class ) - e.g.

Props.get('START.HMS'); props.put('PROP1','1234'); • SampleResult, prev - () - gives access to the previous SampleResult (if any) • sampler - () - gives access to the current sampler • OUT - System.out - e.g. OUT.println('message') • AssertionResult - () - the assertion result The script can check various aspects of the. If an error is detected, the script should use AssertionResult.setFailureMessage('message') and AssertionResult.setFailure(true). For further details of all the methods available on each of the above variables, please check the Javadoc. Yes (unless script file is provided) The following variables are set up for use by the script: • log - () - can be used to write to the log file • Label - the String Label • Filename - the script file name (if any) • Parameters - the parameters (as a String) • args - the parameters as a String array (split on whitespace) • ctx - () - gives access to the context • vars - () - gives read/write access to variables: vars.get(key); vars.put(key,val); vars.putObject('OBJ1',new Object()); vars.getObject('OBJ2'); • props - (JMeterProperties - class ) - e.g. Props.get('START.HMS'); props.put('PROP1','1234'); • SampleResult, prev - () - gives access to the previous SampleResult (if any) • sampler - () - gives access to the current sampler • OUT - System.out - e.g. OUT.println('message') • AssertionResult - () - the assertion result The script can check various aspects of the.

If an error is detected, the script should use AssertionResult.setFailureMessage('message') and AssertionResult.setFailure(true). For further details of all the methods available on each of the above variables, please check the Javadoc. The SMIME Assertion can be used to evaluate the sample results from the Mail Reader Sampler. This assertion verifies if the body of a mime message is signed or not. The signature can also be verified against a specific signer certificate.

As this is a functionality that is not necessarily needed by most users, additional jars need to be downloaded and added to JMETER_HOME/lib: • bcmail-xxx.jar (BouncyCastle SMIME/CMS) • bcprov-xxx.jar (BouncyCastle Provider) These need to be If using the, please ensure that you select ' Store the message using MIME (raw)' otherwise the Assertion won't be able to process the message correctly. Note that timers are processed before each sampler in the scope in which they are found; if there are several timers in the same scope, all the timers will be processed before each sampler. Timers are only processed in conjunction with a sampler. A timer which is not in the same scope as a sampler will not be processed at all. To apply a timer to a single sampler, add the timer as a child element of the sampler. The timer will be applied before the sampler is executed. To apply a timer after a sampler, either add it to the next sampler, or add it as the child of a Sampler.

This timer introduces variable pauses, calculated to keep the total throughput (in terms of samples per minute) as close as possible to a give figure. Of course the throughput will be lower if the server is not capable of handling it, or if other timers or time-consuming test elements prevent it.

Although the Timer is called the Constant Throughput timer, the throughput value does not need to be constant. It can be defined in terms of a variable or function call, and the value can be changed during a test.

The value can be changed in various ways: • using a counter variable • using a JavaScript or BeanShell function to provide a changing value • using the remote BeanShell server to change a JMeter property See for further details. • this thread only - each thread will try to maintain the target throughput.

The overall throughput will be proportional to the number of active threads. • all active threads in current thread group - the target throughput is divided amongst all the active threads in the group. Each thread will delay as needed, based on when it last ran. • all active threads - the target throughput is divided amongst all the active threads in all Thread Groups. Each thread will delay as needed, based on when it last ran.

In this case, each other Thread Group will need a Constant Throughput timer with the same settings. • all active threads in current thread group (shared) - as above, but each thread is delayed based on when any thread in the group last ran. • all active threads (shared) - as above; each thread is delayed based on when any thread last ran. Yes (unless script file is provided) Before invoking the script, some variables are set up in the BeanShell interpreter: • log - () - can be used to write to the log file • ctx - () - gives access to the context • vars - () - gives read/write access to variables: vars.get(key); vars.put(key,val); vars.putObject('OBJ1',new Object()); • props - (JMeterProperties - class java.util.Properties) - e.g. Props.get('START.HMS'); props.put('PROP1','1234'); • prev - () - gives access to the previous SampleResult (if any) For details of all the methods available on each of the above variables, please check the Javadoc If the property beanshell.timer.init is defined, this is used to load an initialisation file, which can be used to define methods etc. For use in the BeanShell script.

Yes (unless script file is provided) Before invoking the script, some variables are set up in the script interpreter: • log - () - can be used to write to the log file • ctx - () - gives access to the context • vars - () - gives read/write access to variables: vars.get(key); vars.put(key,val); vars.putObject('OBJ1',new Object()); • props - (JMeterProperties - class java.util.Properties) - e.g. Props.get('START.HMS'); props.put('PROP1','1234'); • sampler - () - the current Sampler • Label - the name of the Timer • FileName - the file name (if any) • OUT - System.out For details of all the methods available on each of the above variables, please check the Javadoc.

Yes (unless script file is provided) Before invoking the script, some variables are set up in the script interpreter: • log - () - can be used to write to the log file • ctx - () - gives access to the context • vars - () - gives read/write access to variables: vars.get(key); vars.put(key,val); vars.putObject('OBJ1',new Object()); • props - (JMeterProperties - class java.util.Properties) - e.g. Props.get('START.HMS'); props.put('PROP1','1234'); • sampler - () - the current Sampler • Label - the name of the Timer • FileName - the file name (if any) • OUT - System.out For details of all the methods available on each of the above variables, please check the Javadoc. Spidering Example Consider a simple example: let's say you wanted JMeter to 'spider' through your site, hitting link after link parsed from the HTML returned from your server (this is not actually the most useful thing to do, but it serves as a good example). You would create a, and add the 'HTML Link Parser' to it. Then, create an HTTP Request, and set the domain to '.*', and the path likewise.

This will cause your test sample to match with any link found on the returned pages. If you wanted to restrict the spidering to a particular domain, then change the domain value to the one you want. Then, only links to that domain will be followed. Poll Example A more useful example: given a web polling application, you might have a page with several poll options as radio buttons for the user to select.

Let's say the values of the poll options are very dynamic - maybe user generated. If you wanted JMeter to test the poll, you could either create test samples with hardcoded values chosen, or you could let the HTML Link Parser parse the form, and insert a random poll option into your URL test sample. To do this, follow the above example, except, when configuring your Web Test controller's URL options, be sure to choose ' POST' as the method. Put in hard-coded values for the domain, path, and any additional form parameters. Then, for the actual radio button parameter, put in the name (let's say it's called ' poll_choice'), and then '.*' for the value of that parameter. When the modifier examines this URL test sample, it will find that it 'matches' the poll form (and it shouldn't match any other form, given that you've specified all the other aspects of the URL test sample), and it will replace your form parameters with the matching parameters from the form. Since the regular expression '.*' will match with anything, the modifier will probably have a list of radio buttons to choose from.

It will choose at random, and replace the value in your URL test sample. Each time through the test, a new random value will be chosen. Figure 18 - Online Poll Example.

This modifier works similarly to the HTML Link Parser, except it has a specific purpose for which it is easier to use than the HTML Link Parser, and more efficient. For web applications that use URL Re-writing to store session ids instead of cookies, this element can be attached at the ThreadGroup level, much like the. Simply give it the name of the session id parameter, and it will find it on the page and add the argument to every request of that ThreadGroup. Alternatively, this modifier can be attached to select requests and it will modify only them. Clever users will even determine that this modifier can be used to grab values that elude the. Yes (unless script file is provided) Before invoking the script, some variables are set up in the BeanShell interpreter: • log - () - can be used to write to the log file • ctx - () - gives access to the context • vars - () - gives read/write access to variables: vars.get(key); vars.put(key,val); vars.putObject('OBJ1',new Object()); • props - (JMeterProperties - class java.util.Properties) - e.g.

Props.get('START.HMS'); props.put('PROP1','1234'); • prev - () - gives access to the previous SampleResult (if any) • sampler - ()- gives access to the current sampler For details of all the methods available on each of the above variables, please check the Javadoc If the property beanshell.preprocessor.init is defined, this is used to load an initialisation file, which can be used to define methods etc. For use in the BeanShell script.

Yes (unless script file is provided) The script (or file) is processed using the BSFEngine.exec() method, which does not return a value. The following BSF variables are set up for use by the script: • log - () - can be used to write to the log file • Label - the String Label • FileName - the script file name (if any) • Parameters - the parameters (as a String) • args - the parameters as a String array (split on whitespace) • ctx - () - gives access to the context • vars - () - gives read/write access to variables: vars.get(key); vars.put(key,val); vars.putObject('OBJ1',new Object()); vars.getObject('OBJ2'); • props - (JMeterProperties - class java.util.Properties) - e.g. Props.get('START.HMS'); props.put('PROP1','1234'); • sampler - ()- gives access to the current sampler • OUT - System.out - e.g.

OUT.println('message') For details of all the methods available on each of the above variables, please check the Javadoc. Yes (unless script file is provided) The following JSR223 variables are set up for use by the script: • log - () - can be used to write to the log file • Label - the String Label • FileName - the script file name (if any) • Parameters - the parameters (as a String) • args - the parameters as a String array (split on whitespace) • ctx - () - gives access to the context • vars - () - gives read/write access to variables: vars.get(key); vars.put(key,val); vars.putObject('OBJ1',new Object()); vars.getObject('OBJ2'); • props - (JMeterProperties - class java.util.Properties) - e.g. Props.get('START.HMS'); props.put('PROP1','1234'); • sampler - ()- gives access to the current sampler • OUT - System.out - e.g. OUT.println('message') For details of all the methods available on each of the above variables, please check the Javadoc.

Allows to specify dynamic values for HTTP parameters extracted from another HTTP Request using regular expressions. RegEx User Parameters are specific to individual threads. This component allows you to specify reference name of a regular expression that extracts names and values of HTTP request parameters. Regular expression group numbers must be specified for parameter's name and also for parameter's value. Replacement will only occur for parameters in the Sampler that uses this RegEx User Parameters which name matches.

This Pre-Processor schedules a timer task to interrupt a sample if it takes too long to complete. The timeout is ignored if it is zero or negative. For this to work, the sampler must implement Interruptible. The following samplers are known to do so: AJP, BeanShell, FTP, HTTP, Soap, AccessLog, MailReader, JMS Subscriber, TCPSampler, TestAction, JavaSampler The test element is intended for use where individual timeouts such as Connection Timeout or Response Timeout are insufficient, or where the Sampler does not support timeouts. The timeout should be set sufficiently long so that it is not triggered in normal tests, but short enough that it interrupts samples that are stuck.

[By default, JMeter uses a Callable to interrupt the sampler. This executes in the same thread as the timer, so if the interrupt takes a long while, it may delay the processing of subsequent timeouts. This is not expected to be a problem, but if necessary the property InterruptTimer.useRunnable can be set to true to use a separate Runnable thread instead of the Callable.].

This is for use with samplers that can generate sub-samples, e.g. HTTP Sampler with embedded resources, Mail Reader or samples generated by the Transaction Controller.

• Main sample only - only applies to the main sample • Sub-samples only - only applies to the sub-samples • Main sample and sub-samples - applies to both. • JMeter Variable - assertion is to be applied to the contents of the named variable Matching is applied to all qualifying samples in turn. For example if there is a main sample and 3 sub-samples, each of which contains a single match for the regex, (i.e. 4 matches in total). For match number = 3, Sub-samples only, the extractor will match the 3 rd sub-sample. For match number = 3, Main sample and sub-samples, the extractor will match the 2 nd sub-sample (1 st match is main sample).

For match number = 0 or negative, all qualifying samples will be processed. For match number >0, matching will stop as soon as enough matches have been found. If the regular expression does not match, then the reference variable will be set to the default value. This is particularly useful for debugging tests. If no default is provided, then it is difficult to tell whether the regular expression did not match, or the RE element was not processed or maybe the wrong variable is being used.

However, if you have several test elements that set the same variable, you may wish to leave the variable unchanged if the expression does not match. In this case, remove the default value once debugging is complete. No If the match number is set to a non-negative number, and a match occurs, the variables are set as follows: • refName - the value of the template • refName_g n, where n= 0, 1, 2 - the groups for the match • refName_g - the number of groups in the Regex (excluding 0) If no match occurs, then the refName variable is set to the default (unless this is absent). Also, the following variables are removed: • refName_g0 • refName_g1 • refName_g If the match number is set to a negative number, then all the possible matches in the sampler data are processed.

The variables are set as follows: • refName_matchNr - the number of matches found; could be 0 • refName_ n, where n = 1, 2, 3 etc. - the strings as generated by the template • refName_ n_g m, where m= 0, 1, 2 - the groups for match n • refName - always set to the default value • refName_g n - not set Note that the refName variable is always set to the default value in this case, and the associated group variables are not set. See also for some examples of how to specify modifiers, and. This is for use with samplers that can generate sub-samples, e.g. HTTP Sampler with embedded resources, Mail Reader or samples generated by the Transaction Controller. • Main sample only - only applies to the main sample • Sub-samples only - only applies to the sub-samples • Main sample and sub-samples - applies to both. • JMeter Variable - assertion is to be applied to the contents of the named variable Matching is applied to all qualifying samples in turn.

For example if there is a main sample and 3 sub-samples, each of which contains a single match for the regex, (i.e. 4 matches in total). For match number = 3, Sub-samples only, the extractor will match the 3 rd sub-sample. For match number = 3, Main sample and sub-samples, the extractor will match the 2 nd sub-sample (1 st match is main sample). For match number = 0 or negative, all qualifying samples will be processed. For match number >0, matching will stop as soon as enough matches have been found.

The CSS/JQuery selector used to select nodes from the response data. Selector, selectors combination and pseudo-selectors are supported, examples: • E[foo] - an E element with a ' foo' attribute • ancestor child - child elements that descend from ancestor, e.g..body p finds p elements anywhere under a block with class ' body' •:lt(n) - find elements whose sibling index (i.e. Its position in the DOM tree relative to its parent) is less than n; e.g. Td:lt(3) •:contains(text) - find elements that contain the given text.

The search is case-insensitive; e.g. P:contains(jsoup) • For more details on syntax, see: • •. If the expression does not match, then the reference variable will be set to the default value. This is particularly useful for debugging tests. If no default is provided, then it is difficult to tell whether the expression did not match, or the CSS/JQuery element was not processed or maybe the wrong variable is being used.

However, if you have several test elements that set the same variable, you may wish to leave the variable unchanged if the expression does not match. In this case, remove the default value once debugging is complete. No If the match number is set to a non-negative number, and a match occurs, the variables are set as follows: • refName - the value of the template If no match occurs, then the refName variable is set to the default (unless this is absent). If the match number is set to a negative number, then all the possible matches in the sampler data are processed. The variables are set as follows: • refName_matchNr - the number of matches found; could be 0 • refName_n, where n = 1, 2, 3, etc. - the strings as generated by the template • refName - always set to the default value Note that the refName variable is always set to the default value in this case. This is for use with samplers that can generate sub-samples, e.g.

HTTP Sampler with embedded resources, Mail Reader or samples generated by the Transaction Controller. • Main sample only - only applies to the main sample • Sub-samples only - only applies to the sub-samples • Main sample and sub-samples - applies to both. • JMeter Variable - assertion is to be applied to the contents of the named variable XPath matching is applied to all qualifying samples in turn, and all the matching results will be returned.

If checked, then the XML parser will use namespace resolution.(see note below on NAMESPACES) Note that currently only namespaces declared on the root element will be recognised. A later version of JMeter may support user-definition of additional workspace names. Meanwhile, a work-round is to replace: //mynamespace:tagname by //*[local-name()='tagname' and namespace-uri()='uri-for-namespace'] where ' uri-for-namespace' is the uri for the ' mynamespace' namespace. (not applicable if Tidy is selected). XPath is query language targeted primarily for XSLT transformations. However it is useful as generic query language for structured data too. See or for more information.

Here are few examples: /html/head/title extracts title element from HTML response /book/page[2] extracts 2 nd page from a book /book/page extracts all pages from a book //form[@name='countryForm']//select[@name='country']/option[text()='Czech Republic'])/@value extracts value attribute of option element that match text ' Czech Republic' inside of select element with name attribute ' country' inside of form with name attribute ' countryForm'. Determines what happens if a sampler error occurs, either because the sample itself failed or an assertion failed. The possible choices are: • Continue - ignore the error and continue with the test • Start next thread loop - does not execute samplers following the sampler in error for the current iteration and restarts the loop on next iteration • Stop Thread - current thread exits • Stop Test - the entire test is stopped at the end of any current samples. • Stop Test Now - the entire test is stopped abruptly.

Any current samplers are interrupted if possible. Yes (unless script file is provided) The following BeanShell variables are set up for use by the script: • log - () - can be used to write to the log file • ctx - () - gives access to the context • vars - () - gives read/write access to variables: vars.get(key); vars.put(key,val); vars.putObject('OBJ1',new Object()); • props - (JMeterProperties - class java.util.Properties) - e.g. Props.get('START.HMS'); props.put('PROP1','1234'); • prev - () - gives access to the previous SampleResult • data - (byte [])- gives access to the current sample data For details of all the methods available on each of the above variables, please check the Javadoc If the property beanshell.postprocessor.init is defined, this is used to load an initialisation file, which can be used to define methods etc. For use in the BeanShell script.

Yes (unless script file is provided) The script (or file) is processed using the BSFEngine.exec() method, which does not return a value. Before invoking the script, some variables are set up. Note that these are BSF variables - i.e.

They can be used directly in the script. • log - () - can be used to write to the log file • Label - the String Label • FileName - the script file name (if any) • Parameters - the parameters (as a String) • args - the parameters as a String array (split on whitespace) • ctx - () - gives access to the context • vars - () - gives read/write access to variables: vars.get(key); vars.put(key,val); vars.putObject('OBJ1',new Object()); vars.getObject('OBJ2'); • props - (JMeterProperties - class java.util.Properties) - e.g.

Props.get('START.HMS'); props.put('PROP1','1234'); • prev - () - gives access to the previous SampleResult (if any) • sampler - ()- gives access to the current sampler • OUT - System.out - e.g. OUT.println('message') For details of all the methods available on each of the above variables, please check the Javadoc. Yes (unless script file is provided) Before invoking the script, some variables are set up. Note that these are JSR223 variables - i.e. They can be used directly in the script.

• log - () - can be used to write to the log file • Label - the String Label • FileName - the script file name (if any) • Parameters - the parameters (as a String) • args - the parameters as a String array (split on whitespace) • ctx - () - gives access to the context • vars - () - gives read/write access to variables: vars.get(key); vars.put(key,val); vars.putObject('OBJ1',new Object()); vars.getObject('OBJ2'); • props - (JMeterProperties - class java.util.Properties) - e.g. Props.get('START.HMS'); props.put('PROP1','1234'); • prev - () - gives access to the previous SampleResult (if any) • sampler - ()- gives access to the current sampler • OUT - System.out - e.g. OUT.println('message') For details of all the methods available on each of the above variables, please check the Javadoc. Also, an option exists here to instruct JMeter to run the serially rather than in parallel.

Run tearDown Thread Groups after shutdown of main threads: if selected, the tearDown groups (if any) will be run after graceful shutdown of the main threads. The tearDown threads won't be run if the test is forcibly stopped. Test plan now provides an easy way to add classpath setting to a specific test plan.

The feature is additive, meaning that you can add jar files or directories, but removing an entry requires restarting JMeter. A Thread Group defines a pool of users that will execute a particular test case against your server. In the Thread Group GUI, you can control the number of users simulated (number of threads), the ramp up time (how long it takes to start all the threads), the number of times to perform the test, and optionally, a start and stop time for the test.

See also and. When using the scheduler, JMeter runs the thread group until either the number of loops is reached or the duration/end-time is reached - whichever occurs first. Note that the condition is only checked between samples; when the end condition is reached, that thread will stop. JMeter does not interrupt samplers which are waiting for a response, so the end time may be delayed arbitrarily. Screenshot of Control-Panel of Thread Group Since JMeter 3.0, you can run a selection of Thread Group by selecting them and right clicking. A popup menu will appear: Popup menu to start a selection of Thread Groups Notice you have 3 options to run the selection of Thread Groups: • Start: Start the selected thread groups only • Start no pauses: Start the selected thread groups only but without running the timers • Validate: Start the selected thread groups only using validation mode.

Per default this runs the Thread Group in validation mode (see below) Validation Mode: This mode enables rapid validation of a Thread Group by running it with 1 thread, 1 iteration, no timers and no Startup delay set to 0. Behaviour can be modified with some properties by setting in user.properties: • testplan_validation.nb_threads_per_thread_group: Number of threads to use to validate a Thread Group, by default 1 • testplan_validation.ignore_timers: Ignore timers when validating the thread group of plan, by default 1 • testplan_validation.number_iterations: Number of iterations to use to validate a Thread Group • testplan_validation.tpc_force_100_pct: Wether to force Throughput Controller in percentage mode to run as if percentage was 100%. Defaults to false. If selected, threads are created only when the appropriate proportion of the ramp-up time has elapsed. This is most appropriate for tests with a ramp-up time that is significantly longer than the time to execute a single thread. Where earlier threads finish before later ones start.

If not selected, all threads are created when the test starts (they then pause for the appropriate proportion of the ramp-up time). This is the original default, and is appropriate for tests where threads are active throughout most of the test. SSL Manager The SSL Manager is a way to select a client certificate so that you can test applications that use Public Key Infrastructure (PKI). It is only needed if you have not set up the appropriate System properties.

Choosing a Client Certificate You may either use a Java Key Store (JKS) format key store, or a Public Key Certificate Standard #12 (PKCS12) file for your client certificates. There is a feature of the JSSE libraries that require you to have at least a six character password on your key (at least for the keytool utility that comes with your JDK). To select the client certificate, choose Options → SSL Manager from the menu bar. You will be presented with a file finder that looks for PKCS12 files by default. Your PKCS12 file must have the extension '.p12' for SSL Manager to recognize it as a PKCS12 file. Any other file will be treated like an average JKS key store.

If JSSE is correctly installed, you will be prompted for the password. The text box does not hide the characters you type at this point -- so make sure no one is looking over your shoulder. The current implementation assumes that the password for the keystore is also the password for the private key of the client you want to authenticate as. Or you can set the appropriate System properties - see the system.properties file.

The next time you run your test, the SSL Manager will examine your key store to see if it has at least one key available to it. If there is only one key, SSL Manager will select it for you. If there is more than one key, it currently selects the first key. There is currently no way to select other entries in the keystore, so the desired key must be the first. Things to Look Out For You must have your Certificate Authority (CA) certificate installed properly if it is not signed by one of the five CA certificates that ships with your JDK. One method to install it is to import your CA certificate into a JKS file, and name the JKS file ' jssecacerts'. Place the file in your JRE's lib/security folder.

This file will be read before the ' cacerts' file in the same directory. Keep in mind that as long as the ' jssecacerts' file exists, the certificates installed in ' cacerts' will not be used. This may cause problems for you. If you don't mind importing your CA certificate into the ' cacerts' file, then you can authenticate against all of the CA certificates installed.

The HTTP(S) Test Script Recorder allows JMeter to intercept and record your actions while you browse your web application with your normal browser. JMeter will create test sample objects and store them directly into your test plan as you go (so you can view samples interactively while you make them).

Ensure you read this to setup correctly JMeter. To use the recorder, add the HTTP(S) Test Script Recorder element to the workbench.

Select the WorkBench element in the tree, and right-click on this element to get the Add menu ( Add → Non-Test Elements → HTTP(S) Test Script Recorder ). The recorder is implemented as an HTTP(S) proxy server.

You need to set up your browser use the proxy for all HTTP and HTTPS requests. Ideally use private browsing mode when recording the session. This should ensure that the browser starts with no stored cookies, and prevents certain changes from being saved. For example, Firefox does not allow certificate overrides to be saved permanently.

HTTPS recording and certificates HTTPS connections use certificates to authenticate the connection between the browser and the web server. When connecting via HTTPS, the server presents the certificate to the browser. To authenticate the certificate, the browser checks that the server certificate is signed by a Certificate Authority (CA) that is linked to one of its in-built root CAs. If any of the browser checks fail, it will prompt the user who can then decide whether to allow the connection to proceed. JMeter needs to use its own certificate to enable it to intercept the HTTPS connection from the browser. Effectively JMeter has to pretend to be the target server.

JMeter will generate its own certificate(s). These are generated with a validity period defined by the property proxy.cert.validity, default 7 days, and random passwords.

If JMeter detects that it is running under Java 8 or later, it will generate certificates for each target server as necessary (dynamic mode) unless the following property is defined: proxy.cert.dynamic_keys=false. When using dynamic mode, the certificate will be for the correct host name, and will be signed by a JMeter-generated CA certificate. By default, this CA certificate won't be trusted by the browser, however it can be installed as a trusted certificate.

Once this is done, the generated server certificates will be accepted by the browser. This has the advantage that even embedded HTTPS resources can be intercepted, and there is no need to override the browser checks for each new server. Unless a keystore is provided (and you define the property proxy.cert.alias), JMeter needs to use the keytool application to create the keystore entries. JMeter includes code to check that keytool is available by looking in various standard places.

If JMeter is unable to find the keytool application, it will report an error. If necessary, the system property keytool.directory can be used to tell JMeter where to find keytool. This should be defined in the file system.properties. The JMeter certificates are generated (if necessary) when the Start button is pressed.

The cursor is changed to an hour-glass whilst this is happening. When certificate generation is complete, the GUI will display a pop-up dialogue containing the details of the certificate for the root CA. This certificate needs to be installed by the browser in order for it to accept the host certificates generated by JMeter; see for details. If necessary, you can force JMeter to regenerate the keystore (and the exported certificates - ApacheJMeterTemporaryRootCA[.usr .crt]) by deleting the keystore file proxyserver.jks from the JMeter directory. This certificate is not one of the certificates that browsers normally trust, and will not be for the correct host. As a consequence: • The browser should display a dialogue asking if you want to accept the certificate or not.

For example: 1) The server's name ' www.example.com' does not match the certificate's name ' JMeter Proxy (DO NOT TRUST)'. Somebody may be trying to eavesdrop on you. 2) The certificate for ' JMeter Proxy (DO NOT TRUST)' is signed by the unknown Certificate Authority ' JMeter Proxy (DO NOT TRUST)'. It is not possible to verify that this is a valid certificate. You will need to accept the certificate in order to allow the JMeter Proxy to intercept the SSL traffic in order to record it. However, do not accept this certificate permanently; it should only be accepted temporarily. Browsers only prompt this dialogue for the certificate of the main URL, not for the resources loaded in the page, such as images, CSS or JavaScript files hosted on a secured external CDN.

If you have such resources (gmail has for example), you'll have to first browse manually to these other domains in order to accept JMeter's certificate for them. Check in jmeter.log for secure domains that you need to register certificate for. • If the browser has already registered a validated certificate for this domain, the browser will detect JMeter as a security breach and will refuse to load the page. If so, you have to remove the trusted certificate from your browser's keystore.

Installing the JMeter CA certificate for HTTPS recording As mentioned above, when run under Java 8, JMeter can generate certificates for each server. For this to work smoothly, the root CA signing certificate used by JMeter needs to be trusted by the browser. The first time that the recorder is started, it will generate the certificates if necessary. The root CA certificate is exported into a file with the name ApacheJMeterTemporaryRootCA in the current launch directory. When the certificates have been set up, JMeter will show a dialog with the current certificate details. At this point, the certificate can be imported into the browser, as per the instructions below.

Note that once the root CA certificate has been installed as a trusted CA, the browser will trust any certificates signed by it. Until such time as the certificate expires or the certificate is removed from the browser, it will not warn the user that the certificate is being relied upon.

So anyone that can get hold of the keystore and password can use the certificate to generate certificates which will be accepted by any browsers that trust the JMeter root CA certificate. For this reason, the password for the keystore and private keys are randomly generated and a short validity period used. The passwords are stored in the local preferences area. Please ensure that only trusted users have access to the host with the keystore.

Whether to group samplers for requests from a single 'click' (requests received without significant time separation), and how to represent that grouping in the recording: • Do not group samplers - store all recorded samplers sequentially, without any grouping. • Add separators between groups - add a controller named ' --------------' to create a visual separation between the groups. Otherwise the samplers are all stored sequentially.

• Put each group in a new controller - create a new for each group, and store all samplers for that group in it. • Store 1 st sampler of each group only - only the first request in each group will be recorded. The ' Follow Redirects' and ' Retrieve All Embedded Resources ' flags will be turned on in those samplers.

• Put each group in a new transaction controller - create a new for each group, and store all samplers for that group in it. The property proxy.pause determines the minimum gap that JMeter needs between requests to treat them as separate 'clicks'.

The default is 5000 (milliseconds) i.e. If you are using grouping, please ensure that you leave the required gap between clicks. Should headers be added to the plan? If specified, a Header Manager will be added to each HTTP Sampler.

The Proxy server always removes Cookie and Authorization headers from the generated Header Managers. By default it also removes If-Modified-Since and If-None-Match headers. These are used to determine if the browser cache items are up to date; when recording one normally wants to download all the content. To change which additional headers are removed, define the JMeter property proxy.headers.remove as a comma-separated list of headers. Now if JMeter is set to follow the redirect during replay, it will issue the original request, and then replay the redirect request that was recorded.

To avoid this duplicate replay, JMeter tries to detect when a sample is the result of a previous redirect. If the current response is a redirect, JMeter will save the redirect URL. When the next request is received, it is compared with the saved redirect URL and if there is a match, JMeter will disable the generated sample. It also adds comments to the redirect chain.

This assumes that all the requests in a redirect chain will follow each other without any intervening requests. To disable the redirect detection, set the property proxy.redirect.disabling=false Includes and Excludes The include and exclude patterns are treated as regular expressions (using Jakarta ORO). They will be matched against the host name, port (actual or implied), path and query (if any) of each browser request. If the URL you are browsing is ' then the regular expression will be tested against the string: ' localhost:80/jmeter/index.html?username=xxxx'. Thus, if you want to include all.html files, your regular expression might look like: '.*.html(?*)?' - or '.*.html if you know that there is no query string or you only want html pages without query strings. If there are any include patterns, then the URL must match at least one of the patterns, otherwise it will not be recorded.

If there are any exclude patterns, then the URL must not match any of the patterns, otherwise it will not be recorded. Using a combination of includes and excludes, you should be able to record what you are interested in and skip what you are not. Where Do Samples Get Recorded? JMeter places the recorded samples in the Target Controller you choose. If you choose the default option ' Use Recording Controller', they will be stored in the first Recording Controller found in the test object tree (so be sure to add a Recording Controller before you start recording).

If the Proxy does not seem to record any samples, this could be because the browser is not actually using the proxy. To check if this is the case, try stopping the proxy. If the browser still downloads pages, then it was not sending requests via the proxy. Double-check the browser options. If you are trying to record from a server running on the same host, then check that the browser is not set to ' Bypass proxy server for local addresses' (this example is from IE7, but there will be similar options for other browsers). If JMeter does not record browser URLs such as or try using the non-loopback hostname or IP address, e.g. Or Handling of HTTP Request Defaults If the HTTP(S) Test Script Recorder finds enabled directly within the controller where samples are being stored, or directly within any of its parent controllers, the recorded samples will have empty fields for the default values you specified.

You may further control this behaviour by placing an HTTP Request Defaults element directly within the HTTP(S) Test Script Recorder, whose non-blank values will override those in the other HTTP Request Defaults. See for more info. User Defined Variable replacement Similarly, if the HTTP(S) Test Script Recorder finds (UDV) directly within the controller where samples are being stored, or directly within any of its parent controllers, the recorded samples will have any occurrences of the values of those variables replaced by the corresponding variable. Again, you can place User Defined Variables directly within the HTTP(S) Test Script Recorder to override the values to be replaced. See for more info. Herr Der Ringe Schlacht Um Mittelerde 2 Vollversion Gratis Download here.

Introduction This article provides step-by-step instructions for installing your certificate in Apache HTTP Server. Note that as of version 2.4.8, the default configuration options have changed. Process • Copy certificates to your server. This includes your server certificate, private key, and an intermediate certificate.

Your server certificate can be obtained from the delivery e-mail. Alternatively you can get it from your GlobalSign Account by clicking Edit on your order and copying the Certificate PEM Format text from the details. The private key would have been generated along with the certificate signing request (CSR); it may very well already be on the server.

If the private key is lost, you will need to reissue your certificate. The intermediate certificate used will vary depending on product type. Click your product type in our section to identify the correct cert. • Open your Apache configuration file for editing. This will generally be found in one of the following locations, depending on your OS: On CentOS/RedHat: /etc/httpd/httpd.conf /etc/httpd/sites-enabled/name-of-virutalhost.conf On Debian/Ubuntu: /etc/apache2/apache2.conf /etc/apache2/sites-enabled/name-of-virtualhost.conf The configuration may be in different location.

A detailed mapping of configuration paths can be found on the. • Configure your virtual host to use the certificates. Locate the virtual host for your site.

DocumentRoot /var/www/examplesite ServerName example.com www.example.com SSLEngine on SSLCertificateFile /path/to/examplesite.crt SSLCertificateKeyFile /path/to/privatekey.key SSLCertificateChainFile /path/to/intermediate.crt Point the following directives to the corresponding certificate: SSLCertificateFile - This should point to your server certificate. SSLCertificateKeyFile - This should point to your server's private key. SSLCertificateChainFile - This should point to the intermediate certificate for your product.

Note: As of Apache 2.4.8, the SSLCertificateChainFile directive was deprecated and SSLCertificateFile was extended to support intermediate certificates. Adding the intermediate certificate to the end of your certificate will create a chain file for your server. • Test your updated configuration. Depending on your system, run the command: apachectl configtest or apache2ctl configtest This will detect any errors in your configuration such as mismatched public & private keys, or an incorrect path. • Restart the Apache service. For older versions of Red Hat Enterprise Linux use init scripts as stated below: CentOS/RedHat: service httpd restart Debian/Ubuntu: service apache2 restart For Red Hat Enterprise Linux 7 or CentOS 7.0 use the following commands: CentOS/RedHat: systemctl restart httpd.service Debian/Ubuntu: systemctl restart apache2.service Note: Some Apache configurations may show an entry for SSLCACertificateFile. This field is only needed if you use Apache for client authentication.

The SSLCACertificateFile would point to a CA certificate or directory of CA certificates that issue certificates you accept for client authentication.