jpcvtest (executes measurement tests)

Format

Format 1

jpcvtest -wtfile Web-transaction-file-name -wtname Web-transaction-name [ -t timeout-period (seconds)] [-s] [-v]

Format 2

jpcvtest -n measurement-condition-ID [-s] [-v]

To Page Top

Function

The functions and usage patterns of each format of the jpcvtest command are described below. For details about measurement test usage patterns, see 2.1.3 Web transaction measurement test.

Format 1

Based on the Web transaction and timeout period specified as arguments, this command immediately executes a measurement test and outputs measurement results to the standard output.

The Web transaction file name and Web transaction name that are used for a measurement test are directly specified as arguments.

Use this format when conducting a measurement test for Web transactions that are not defined in the measurement condition registration file. The main usage patterns for this format are shown below.

• Verifying whether Web transactions can be measured using a Web transaction file that is created when the product is installed

• Preliminary checking of a new Web transaction file that is created before it is registered in the measurement condition registration file, while production operations are in progress

Format 2

This command immediately executes a measurement test for a Web transaction with the measurement condition ID specified as an argument and outputs measurement results to the standard output.

A measurement test is executed by reading definition information (a Web transaction file name, Web transaction name, and timeout period) related to the measurement condition ID specified as an argument from the measurement condition registration file (esptask.xml). If the measurement target with the specified measurement condition ID is not a Web transaction, the measurement result is output as an error. Note that this format cannot be used on a standby node in a cluster environment.

Use this format when conducting a measurement test for an existing Web transaction that is defined in the measurement condition registration file. This format can be used in an environment where Web transactions are measured using PFM - Agent for Service Response, in the following situations:

• To verify whether Web transactions can be measured after Web content or server settings on the monitored server are changed

• To verify whether Web transactions can be measured after the definitions for PFM - Agent for Service Response (such as definitions in a Web transaction file, measurement conditions, passwords, and authentication information in a certificate file) are changed

• To check whether the monitored server is operating when there are no changes to the settings or definitions

There are notes about using this format. See 1 in Notes below.

To Page Top

Execution permission

Administrator permissions

To Page Top

Storage folder

installation-folder\agtv\probe\bin

To Page Top

Arguments

To Page Top

Notes

1. PFM - Agent for Service Response performs a syntax check when the service is started or reloaded. If a syntax error^# is found in the Web transaction file registered in the measurement condition registration file, other measurements by the probe also stop. This is because the Extensible Service Probe service (for measuring response performance) stops when the PFM - Agent for Service Response service is started or reloaded

   For this reason, watch out for syntax errors when executing the jpcvtest command in format 2. When you create a new Web transaction file, we recommend that you check for any syntax errors by executing the jpcvtest command in format 1 before registering the Web transaction file in the measurement condition registration file. When you modify an existing Web transaction file, we also recommend that you check for any syntax errors by executing a measurement test before starting or reloading the service.

   #

   Syntax errors include the following cases: XML tags contain errors, or no password is set even though the user to be authenticated is specified (including cases where a password has not been correctly registered with the esppasswd command).

   For details about the format of a Web transaction file, see 8.5 Web transaction files.

2. Multiple instances of the jpcvtest command cannot be executed at the same time. If multiple instances of this command are executed at the same time, the execution results of all the instances except the first one are indicated as an error.

3. If the test measurement by the jpcvtest command conflicts with test measurement by the probe, the jpcvtest command does not suppress the conflict but follows the specifications on the monitoring target. For example, if there is a restriction that prevents the monitored Web page from being accessed simultaneously, the measurement fails.

4. If you change the definitions for PFM - Agent for Service Response before executing the jpcvtest command, back up the definition files to be changed beforehand.

5. If the jpcvtest command is executed in format 1, and a message with a measurement condition ID is output, the measurement condition ID is indicated as 0.

To Page Top

Return values

To Page Top

Result report format

• Result report format when the command is executed in format 1

  KAVK08333-I Web transaction test has started. KAVK08334-I Web transaction test has succeeded. ResultCode=0 == Test report ========================== Web Transaction Filename: wtdemo.xml ...The Web transaction file name specified by the command argument Web Transaction Name: wtdemo1 ...The Web transaction name specified by the command argument Service Type ID: 110 ... Service type ID (fixed as 110)#1 Measurement Start Time: 2014/06/18 19:46:52 ... Measurement start time Measurement End Time: 2014/06/18 19:46:52 ... Measurement end time Result Code: 0 ... Result code#2 ========================================= KAVK08336-I Web transaction test has ended. KAVK42005-I The command was successfully executed.

• Result report format when the command is executed in format 2

  KAVK08333-I Web transaction test has started. KAVK08334-I Web transaction test has succeeded. ResultCode=0 == Test report ========================== Measurement Condition ID: 100 ...The measurement condition ID specified by the command argument Service Type ID: 110 ... Service Type ID (fixed as 110)#1 Measurement Start Time: 2014/06/18 19:46:52 ... Measurement start time Measurement End Time: 2014/06/18 19:46:52 ... Measurement end time Result Code: 0 ... Result code#2 ========================================= KAVK08336-I Web transaction test has ended. KAVK42005-I The command was successfully executed.

#1

For details about service type IDs, see Table 10-12 Service type IDs.

#2

For details about result codes, see Table 10-11 Result code.

To Page Top

Example 1 (executing a measurement test)

Three examples of using this command are shown below, based on the definitions in the following Web transaction file (wtdemo.xml):

In the following command usage example, a measurement test is executed for the Web transaction called wtdemo1 in the above Web transaction file (wtdemo.xml).

If a measurement test is executed and succeeds, the following result report is output:

If a measurement test is executed, and an error is indicated in the measurement result, an error message is also output as in the following output example. In this example, an HTTP request failed. For details about the descriptions and actions to take for the messages that are output, see 12.4 Messages.

To Page Top

Example 2 (collecting information to check the cause of the error detected by a measurement test)

By executing the command with the -v option specified, you can output information that can be used to investigate the cause of the error detected by a measurement test. (This information is any information other than measurement results, such as HTTP requests and response headers.) A command usage example is as follows:

Based on the case where an HTTP request failed as shown in Example 1 (executing a measurement test), the following section explains how to investigate error causes according to the information output by the -v option.

Here, assume that the browser can successfully access the URL (success.php) defined in the Web transaction file when the measurement test detects the error that causes the HTTP request to fail.

When the command is executed with the -v option specified, the following information is output:

The following is an example of command output with the -v option specified. HTTP request and response header information is output separately for each step.

** Step(No.1) ***************************
Resolve address "testmachine1"->"172.16.233.12"
HTTP Request {
    GET /~test/jp1pfm/SRmemo/wtdemo/wtdemopage1/index.php HTTP/1.0
    Host: testmachine1:80
    Connection: close
    User-Agent: PFM - Agent for Service Response (Windows)
    Accept: */*
}
HTTP Response {
    HTTP/1.1 200 OK
    Date: Wed, 18 Jun 2014 10:30:55 GMT
    Server: Apache/2.0.52 (Red Hat)
    X-Powered-By: PHP/4.3.9
    Content-Length: 548
    Connection: close
    Content-Type: text/html; charset=none
}
Step response time :0.084 sec

** Step(No.2) ***************************
Resolve address "testmachine1"->"172.16.233.12"
HTTP Request {
    GET /~test/jp1pfm/SRmemo/wtdemo/wtdemopage1/success.php HTTP/1.0
    Host: testmachine1:80
    Connection: close
    User-Agent: PFM - Agent for Service Response (Windows)
    Accept: */*
}
HTTP Response {
    HTTP/1.1 404 Not Found
    Date: Wed, 18 Jun 2014 10:30:55 GMT
    Server: Apache/2.0.52 (Red Hat)
    X-Powered-By: PHP/4.3.9
    Content-Length: 0
    Connection: close
    Content-Type: text/html; charset=none
}

In the above output example, the first step succeeded with HTTP status code 200 (OK), while the second step accessed success.php and received status code HTTP404 (Not Found) from the monitored server (testmachine1).

This fact clarifies the following two points:

1. The browser was able to successfully access the URL (success.php) defined in the Web transaction file.

   The resource for success.php exists on the monitored server.

2. Both the first and second steps sent HTTP request messages to the same monitored server (testmachine1), and the only difference between them is the URLs that they accessed (index.php and success.php). When success.php was accessed, an HTTP404 error occurred.

   It is very likely that the content of success.php itself could have been the cause of an HTTP404 error.

Now, if we look at the content of success.php (which resulted in an HTTP404 error) on the monitored server, we find that the URL page has the following restriction: the page references the User-Agent section of each HTTP request message sent to the monitored server, and returns an HTTP404(Not Found) error to requests received from any browsers other than Internet Explorer. (Note that the following content of success.php is just a sample for explaining this usage example.)

The restriction imposed on this page cannot be avoided by using the content of the standard User-Agent settings.

To make HTTP requests from PFM - Agent for Service Response and avoid the restriction imposed on this page, you need to change the User-Agent settings to match the contents of HTTP requests from Internet Explorer. As shown in the following setting example, you can use a method to set the <USER_AGENT> tag in the Web transaction file. For details about how to set the <USER_AGENT> tag, see 8.5.2(1) <TRANSACTION_PARAM> tag.

• Example of setting the <USER_AGENT> tag

  Set the <USER_AGENT> tag to match the environment that you are using.

  <?xml version="1.0" encoding="Shift_JIS" standalone="no"?> <!DOCTYPE TRANSACTION_LIST SYSTEM "espwebtrans.dtd"> <TRANSACTION_LIST> <TRANSACTION> <TRANSACTION_PARAM> <TRANSACTION_NAME>wtdemo1</TRANSACTION_NAME> <USER_AGENT>Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)</USER_AGENT> </TRANSACTION_PARAM> : </TRANSACTION> </TRANSACTION_LIST>

To Page Top

Example 3 (checking measurement test results separately for each scope)

To check measurement results not only for the entire Web transaction but also for individual scopes that are user-defined in Web Recorder, execute the command with the -s option specified, as follows:

The following output example shows the information output for individual scopes.

The information output under (scopeALL) indicates the measurement test results for the entire Web transaction, while the information output under (scope1) and (scope2) indicates the measurement test results for the individual scopes.

To Page Top