Rajeshavanthi 2700022MCX Visits (489)
Often times when you perform user load executions in IBM Rational Performance Tester (RPT), you come across various connection errors depending on the schedule design, network issues and so on. Its also interesting to see that sometimes the connection time-out error takes place only for a few of the virtual users as compared to the rest where the execution succeeds without any failure notice.
RPT is a load generation performance testing tool and mimics most of the recorded behavior during playback of the scripts. So overall whatever the connection times, response times, think times and so on are captured during recording is being utilized during playback action.
Considering this fact, the reason for time out behaviors could be many, but mostly related to how the application is responding to the requests during playback as compared to recorded mode. On the other hand RPT does allow you to modify Time-Out behavior of a recorded test. To access this setting:
Timeout: Specifies the time threshold for initiating the action that is selected for Timeout action. The test will wait up to this amount of time for a response. If the response comes back before the timeout limit, the test will proceed to the next action immediately when the response is received. The Timeout action and Timeout value settings apply to every page in the test.
That being said, there could be several application behaviors which can also impact the time-out properties of requests/response data. Sometimes, the host application server locks out your IP address, because the server notes that your IP address sends several virtual users.
Let's take another such frequently occurring error. For example:
Error occurred during connection to server 'ser
So what does this indicate? In its literal sense RPT tried to open a connection while trying to execute a request to the server for a secondary request (i.e. not the primary but something like a gif) and RPT was unable to open the connection to the server.
It's probably worth looking at all the previous requests and responses. Use the Protocol viewer where you can see the browser view or the actual response from the server. If there are no errors then the symptoms indicate a problem with the application or server under test.
In addition to this, if the network connectivity and bandwidth between the host controller and its agents are not uniform, then this might cause communication errors.
Rajeshavanthi 2700022MCX Visits (538)
IBM Rational Performance Tester (RPT) supports various error handling conditions which can help you narrow down the identification of performance bottlenecks of the given applications. You can specify how error conditions are handled when running a test or schedule. Error conditions include verification point failures, connection failures, server timeouts, custom code alerts, and problems with data correlation.
Say, for example, if you encounter an issue in the first transaction and based on this you want to exit from all the transactions and start from the first transaction all over again. It could also be a case where you cannot continue to next iteration as the loop is provided in the schedule. Let's discuss one simple scenario on similar lines.
Below are the Transactions available in the script:
Below are the HTTP pages available in the Transaction’s:
What happens if you select Exit Transaction and outermost in a request available in ‘Log
So, if you select Exit Transaction and outermost in a request available in ‘Log
RojaAyyagary 270005QDMN Visits (657)
Run and Control Rational Performance Tester executions and Reports using a web browser - Part 1
Table of Contents
- Configure Web Reports
- Execution Control
- Display Report
- Export Data
- Customize Web Reports
Traditionally Rational Performance Tester execution is monitored, controlled and reports can be viewed in the workbench. Recently a new feature has been introduced that would allow the test execution be monitored, controlled, view reports, and export data if needed using a browser on another system. Reports can be customized as well.
This article explains how to configure, use web reports in Rational Performance Tester. This feature is being improved as new versions of RPT get released. This document refers to RPT v188.8.131.52. Customization of Reports would be discussed more in detail in Part 2 of this article.
Configure Web Reports
To enable web reports, go to RPT -> Window -> Preferences -> Test -> Performance Test Reports -> Web Reports -> select Allow remote access from a web browser check box.
For Non-secure web access, select No security is required to access reports check box. By default, the non-secure port number for web reports is 8080. If this port number is used by another service, you can provide another port number.
To provide security for web reports, select the Security is required to access reports check box.
To access reports remotely, on another computer, open a web browser and type http
To control the schedule execution remotely using a browser, select Allow control of schedule execution from the web browser check box as shown in the image below.
When accessed remotely during execution of schedule, it appears similar to the screen below. Using this, it is possible to Change Number of Users, Manage Synchronization Points, Stop Test Run, Change Stage Duration and Change Log Level
Rational Performance Tester Web Reports can display Custom Reports, Protocol Independent Reports, Display Service Report, HTTP Reports, Socket Reports, TN3270 Reports and Selenium Execution Report
Under HTTP Reports - Page Performance Report you will find the following tabs.
Page Performance Report
Response Vs Time Summary
Server Health Summary
You can export reports in HTML format for others to view; export an entire run or specific counters to a CSV file for further analysis; or export report metadata (templates) so that other users can generate any custom reports that you have created.
You can also export the web-based charts as image.
If the default reports do not address your needs, you can create a new customized report.
Customizing Web Reports will be discussed more in detail in Part 2 of this article.
Discussion about RPT and schedule execution error "The workbench received notification that the execution process on Driver <<Agent Machine>> has terminated"
Rajeshavanthi 2700022MCX Visits (545)
IBM Rational Performance Tester (RPT) is a performance test tool which measures the performance of an IT system by generating load on it and measuring the response times of the system under load. RPT generates load by simulating the actions on the system of multiple simultaneous users. In order to achieve this, you might have to design the schedule with appropriate user load defined and configure the locations where these pre-defined user load needs to be executed.
Often times, when you perform such actions where the user loads are pushed on to the agent machine, you might / might not encounter various errors which could be related to insufficient memory defined for the execution, or network connection problems and so on....
This article specifically discusses one such error which is contributed by the way the RPT v184.108.40.206 agent component contributes to the schedule execution and the occurrence of this error holds good for any higher versions of RPT. However, the following solution is restricted for those who are working on the RPT v220.127.116.11 release.
Error: The workbench received notification that the execution process on Driver <<Agent Machine>> has terminated"
The above error might occur even when you try executing a schedule (irrespective of the virtual user load defined) locally on the RPT workbench or explicitly on external Agent machine. You might get involved in various troubleshooting methods such as :
6. Restart the workbench machine and agent machines
7. Configure the schedule with default settings by reducing the logging levels, set the user load = 1vu and execute the schedule
Despite attempting all these methods, the error persists, irrespective of the user load defined. Note that this is a known behavior in RPT 18.104.22.168 with deployment of cross-project assets. You can upgrade to RPT v8.6 where the problem is fixed.
RojaAyyagary 270005QDMN Visits (714)
Ever wondered how you could split a large test into small scripts? Also interested in playing back scripts from multiple protocols in a single schedule?
Compound tests help you to organize smaller tests into scenarios that can then be run end-to-end. Each of the smaller tests in a compound test can run on a different domain if required, such as a mobile device, or a web browser, and so on.
If you need to combine various tests into a single workflow or end-to-end scenario, you can organize the tests into a compound test. Each test may perform a part of the scenario. Each test may also run in a different domain, for example, a web browser or a mobile device. A typical example of a compound test is an online buying workflow. You may have built smaller tests for each part of an online purchase transaction, such as "log on", "log out", "view item", "add to cart", and "check out". You can combine these tests into a single flow in a compound test. When the compound test is run, its individual tests are run in sequence.
The types of tests you can combine into a compound test depend on the testing capabilities you have purchased. If you have purchased only mobile testing capabilities, you can combine tests on mobile applications into a compound test. If you have purchased additional testing capabilities along with mobile testing, you can also combine tests built using Selenium, HTTP tests, Socket tests, Citrix tests or SAP tests into a compound test.
Compound tests can have the following:
When you run a compound test, its test elements are run in the order defined in the compound test. This compound test consists of WebUI test and SAP test.
When a compound test run is completed, a Test Log is shown in the Test Execution perspective. You can work with the information in the test log and also generate test result reports.
You can create a compound test in a test workbench project. If you have an existing compound test, you can import the test to a test workbench project.
Importing a compound test into a Test Workbench project
You can import a compound test into a test workbench project.
To test the performance of multiple tests, you can add all the tests to a compound test and add the compound test to a user group. When you run a schedule, all the tests in the compound test are run in a sequential order.]
For additional information please refer to the Compound Tests topic in the IBM Knowledge Center.
RojaAyyagary 270005QDMN Visits (903)
It is quite useful to be able to get notifications when a run completes. This feature is available in IBM Rational Performance Tester (RPT) 8.7.
To stop a test gracefully without causing incomplete page hits, select the Active actions are allowed to complete if stop requested check box at Window > Preferences > Test > Test Execution.
To receive email notification for the status of the run, specify the email properties in Window > Preferences > Test > Test Execution.
Note: If you run an HTTP schedule on a remote Macintosh computer, the test fails. The cipher suite that is used for recording must be available in Oracle JDK on the Macintosh computer. For example, you can use TLS_
Using this feature you can get notified after your schedule, test and compound test run completion. Multiple email addresses can be separated by comma. Sample email message that would be sent.
Rajeshavanthi 2700022MCX Visits (724)
There are several questions which come up when you are performance testing your application using IBM Rational Performance Tester (RPT). Among all such questions, let's discussion on question like "How to measure the client side page rendering with RPT?" You might say, that you script measuring only the downloading of multiple request/ response for the specific click event and its not capturing the service level agreement statistics to display the downloaded request\response as per the browser level. It could also be a case where, when a script is recorded in RPT, the manual navigation from one page to another takes a lot of time. However, when the script is played back, the response times vary less when compared to what you see manually.
Now, lets look at this from RPT perspective.
IBM Rational Performance Tester is a server load testing tool, designed to measure effects of multiple users on a server. As such it does not make use of a client side browser instead simply interacting with the server
As you know, RPT is used to measure the response time between the fist byte sent in the page's first request and last byte received during the response from the server. The client side experience (how long for a page to be
So in short, there exists no straight forward way to get the measurement metrics pertaining to the client side browser rendering in RPT. However, The client side rendering may be captured as 'Client processing delay' in the recorded test. There may be counter(s) that measure the net server response time but there could be no counters for client rendering. That is understandable because there is no "client" and so no "rendering" that actually takes place when a load is being driven by RPT.
Here's a short note on the impa
RPT Schedule execution on local machine results in error: com/ibm/lang/management/OperatingSystemMXBean
Rajeshavanthi 2700022MCX Visits (682)
IBM Rational Performance Tester (RPT) supports schedule execution to be carried out on a separate controller machine (Agent machine), which in fact is a recommended way of script execution. It also supports, to an extent, executing the minimal amount of user load execution locally on the workbench machine (not recommended for production level testing).
When executing a schedule under RPT
The following attempts were made to debug this further:
Rajeshavanthi 2700022MCX Visits (903)
There are various performance testing tools in market and it's advisable for a tester to do a sort of comparison in-terms of the product functionality.
Under Load Runner you could see following options made available
So there could be questions as to whether RPT provides similar functionality or how would the virtual user execution gets handled in RPT.
What happens if you specify 100 virtual users in the RPT schedule. Say, you have 10 user groups each one has an unique script with it. So10 users per user group, totally 100.
RPT does not require a thread per test not it does require a thread per virtual user. When an individual action is being executed one thread is used.
One example of an action is an HTTP request. One thread is required to open a connection, if necessary, and write the request. Reading the response from the server is non-blocking. When data is available one thread is required to read the data and perform any processing required. Another example of an action is Custom Code. During the execution of the Custom Code exec() method one thread is required.
In general, For the HTTP protocol the RPT engine will create a thread as needed up to a maximum of 500 threads. The need to execute an action (eg request send or response) and unavailability of a free thread is what controls creation of additional threads.
Unless there is some specific problem it is highly recommended to let RPT control the creation and deletion of threads.
So, if you are looking it specifically from RPT perspective, then the agent starts execution with 10 worker threads
However if you are interested to control the threads, then the following system properties can influence thread control. These apply to the execution engine (ie location or agent) so a general property for the location must be created to set these system properties. For each location you must create a property called RPT_VMARGS and set it accordingly.
The default values are
-DrptThreadCount=10 (Initial number of worker threads)
dmmckinn 1200006SCS Visits (1149)
In continuing on the topic of Performance testing, Vaughn Rokosz takes a look at some of the common reasons performance tests can fail, and suggests ways of tuning your servers to avoid the common issues.
Take a look at his latest article that includes the following:
For your convenience, here is the link to the previous article on the subject: Creating a perf
dmmckinn 1200006SCS Visits (947)
Looking for information about how to build performance simulations?
Building a good simulation of a user population requires expertise at many levels, including:
In the following article Vaughn Rokosz, a technical lead for the CLM performance team, shares some of his experiences with building performance simulations of the Jazz products. He walks through a simple example demonstrating how to build a simulation of a user population that is creating work items in Rational Team Concert. He also shares some of the things used to make the development of performance simulations simpler by attaching the Rational Performance Tester project that he used when working through the example.
Stay tuned for part 2...
Check out these newly published videos for IBM Rational Performance Tester.
Rajeshavanthi 2700022MCX Visits (981)
You could see the 'Additional delay' under Client processing delay section for each request, under Advanced tab.
What happens if you make this delay to zero??
Does the play back show much difference in overall response time?
Generally, the time taken to load the entire page outside IBM Rational Performance Tester (RPT) cannot be mapped to the time taken to load the same page when invoked via RPT recorder. There are lot of parameters that RPT, as a load performance testing tool, accounts for (such as the traffic and connection information).
Also, RPT processes these Client side delays in parallel or sequentially depending on how the application server returns them. Sometimes if you try modifying/disabling the client processing delay value, it may also disable the immediate transaction under Rational Performance Tester. Because, practically speaking, when you disable a request, you potentially invalidate some delays because in theory the disabled request could have been the basis for a delay. Therefore, RPT automatically recalculates the delays on the page when you disable a request. That is, if a later request used the disabled one as a base, the later delay request should be adjusted.
Now, let's come to your question about why such discrepancy between the response in the browser and RPT...
Often times when you see response times that are inaccurate it is because of recording your actions too fast and so you end up with more than one page being combined together. When recording, you need to be mindful and make sure to pause between mouse clicks. Do an action and wait 5 seconds before continuing on to the next action. You also need to pay attention to where your mouse is and make sure you have no "hover gifs" that you accidentally cause to be sent to the server while recording.
To see if you have these problems you have two things you can look at.
1. Open the test and click on the name of the test under test Contents in the tree. Click Select->Request. On the right hand side you will see a table of all requests in your test. Look at the delay column and look for really large delay values. If you have these, they are usually caused by recording too quickly, and act as an "embedded" think on the page. The Client Delay is supposed to simulate how long your client took to process the data from the server before sending the next piece of data. When you record too quickly, these values can be skewed. You can also go to a specific page that is taking too long and look at those specific requests. You can use the same Select button, or you can go to the Advanced tab of each request and look at its delay.
2. If you find the delays are your problem, then you can split the page where the delays are long since this was probably supposed to be two pages. This will move that delay to be the think time of the page which would be more accurate. You can also go to Wind
Also remember that when doing recording, we will capture each connection that was used and will send out the requests on the same connection that they were sent on originally. If you had two connections sending requests at record time, we will send requests on two connections at execution time. If you see a really long client delay, then look at that request in detail to determine if it was something that was sent by a user gesture or as a result of the primary request.
vjagadeesh 2700063KJN Visits (992)
Rational Performance Tester supports the TN3270 protocol. However, the TN5250 protocol is still undergoing testing.
The recording of the application using TN5250 protocol is possible using the Socket protocol, as there is no specific protocol recorder provided for this. Identifying and debugging issues which arise during a re-run of the recorded test is difficult using the Socket protocol. Although it is not advisable to use the Socket protocol; there is no other option currently available to use Rational Performance Tester with applications using the TN5250 protocol.
PaulLiskay 06000284J3 Visits (1104)
How to do a silent install of IBM Rational Performance Tester (RPT), or the RPT Load agent is a common topic. To do one on Linux is a bit trickier than on Microsoft Windows because most people are more familiar with Windows than Linux. Don't worry, it's still relatively easy and straight forward.
The approach I took was:
1. download IM 1.8.2 and the RPT 8.7 Agent repositories
2. copy from Windows machine to Linux machine using pscp, a Windows version of scp (secure copy)
3. install the standalone Installation Manager 1.8.2 for Linux
4. run that Installation Manager in GUI mode to create a response file needed for the silent install
5. then run Installation Manager from the command line using the response file generated in step 4 to install the agent silently.
Here's the steps
1. download IM 1.8.2 from htt
2. copy to Linux machine, I'm copying to /tmp/IM182
3. unzip on Linux machine to /tmp/IM182
[root@citmx373 IM182]# unzip age
4. install IM
[root@citmx373 IM182]# pwd
5. copy the agent to the Linux machine, I'm copying to /tmp/RPT87Agent
6. unzip it
[root@citmx373 RPT87Agent]# pwd
7. run IM in GUI mode to create a response file
[root@citmx373 eclipse]# pwd
8. Verify creation of response file
root@citmx373 eclipse]# ls /tmp
9. Do the silent install using the response file just created
[root@citmx373 eclipse]# pwd
10. Verify installation.
Check that the majordomo.config file exists and has the right hostname of the RPT workbench. Then check if the agent is started.
[root@citmx373 Majordomo]# pwd
11, Check agent status on RPT workbench by clicking on the agent status icon
PaulLiskay 06000284J3 Visits (1540)
Licensing can be confusing for Rational Performance Tester (RPT). Here's an overview of the various types of licenses for RPT along with their limitations.
1. 30 Day Trial
2. Rational Performance Tester or Rational Test Workbench Product Activation kit.
3. Rational Performance Tester or Rational Test Workbench PVU Activation kit
4. Rational Performance Tester or Rational Test Workbench Floating License
5. Virtual User licenses
6. Rational Performance Tester or Rational Test Workbench Floating License for PVU
7. Optional Protocol Extension Floating License
mquimby 060001FAVB Visits (1741)
There are some new videos published to the IBM
Rational Performance Tester
Rational Team Concert
Rational Developer for i
Soumya Y Shanthimohan 270004GAQS Visits (1788)
IBM Rational Performance Tester (RPT) is a tool for automated performance testing of web and server based applications.
It allows users to create tests that mimic user transactions between an application client and server.
RPT captures data at the protocol level and supports applications based on the below protocols:
During test execution, these transactions are replicated in parallel to simulate a large transaction load on the server. Server response time measurements are collected to identify the presence and cause of any potential application bottlenecks.
RPT test playback does not invoke the client of the application you are testing. RPT does load testing only on the server (no testing is done against the client).
Soumya Y Shanthimohan 270004GAQS Visits (1411)
A scenario where, the IBM Rational Performance Tester (RPT) recording showed the message: 'This program cannot display the webpage'.
The script also had the required certificates in place.
Soumya Y Shanthimohan 270004GAQS Visits (1702)
What is an IP alias
IP aliasing is associating more than one IP address to a network interface.
IP aliasing in RPT
By default, when you run a schedule, each virtual user has the same IP address. However, you can make each virtual user appear as though it is running on its own host. To do this, you configure IP aliases on the host computer (RPT workbench), and enable IP aliasing in the schedule. When you run the schedule, the network traffic will appear to be generated by multiple hosts.
To avoid IP conflicts, the IPs have to be legitimate, available within the same subnet, and blocked for distribution.
Configuring IP aliases for a remote Windows location
To make it appear that a virtual user has its own IP address during a schedule run, configure IP aliases for each Windows remote location.
Now, when you run the schedule, it will give the impression that the network traffic is being generated from multiple hosts.
Note: To add multiple IP aliases, use the netsh command, as shown in the following example:
The ntcmds.chm file, typically located in C:\WINDOWS\Help, contains more details about the netsh command. When you are finished with the IP aliases, use the following command to remove them:
You can also use a batch file to add and delete the aliases.
Enabling virtual users to use IP aliases
After you have configured aliases at on remote computers, you set the schedule so that the virtual users can use the configured IP aliases.
To set the schedule so that the virtual users will use the IP aliases during a run:
Assignment of IP addresses for each virtual user in RPT
When IP aliases is enabled, it is expected that each virtual users have unique IP address available in order to emulate unique virtual users. However in some circumstances the number of IP address available may be less than the number of virtual users.
The answer to this is, when the location has IP aliasing enabled, RPT will ask the agent computer how many IP addresses it has available. It is up to you to have already configured the computer with these IP addresses. By default, RPT will use all IPv4 (but not IPv6) address available. You can also restrict the selection to IP addresses on particular interfaces.
If there are more virtual users on the location than there are IP addresses (which would normally be the case), RPT will distribute the virtual users evenly (more or less) across the available IP addresses. For example, if your location has IP addresses 192.22.22.02, 192.22.22.03, and 192.22.22.04 and you ran 10 users on the location, you would have a distribution similar to:
192.22.22.02: Users 1, 4, 7, 10
192.22.22.03: Users 2, 5, 8
192.22.22.04: Users 3, 6, 9
Identifying the originating IP address for each Virtual Tester
By default, when you run multiple Virtual Testers the originating IP address will be the IP address of the system hosting the individual Virtual Tester. However, RPT does have a feature (IP Aliasing) that allows you to assign a specific set of IP addresses per Virtual Tester (See the topic ‘Emulating network traffic from multiple hosts’ in RPT online help). If you have IP aliasing set up, there are two ways to verify the originating IP address.
You can see the IP address that a virtual Tester is using by setting the Test Log level of your schedule to ‘All’ and then checking the Extended Properties of a request in the Test Log after a playback. The originating address of the virtual user will appear as the "Local IP Address".
Alternatively, there is a custom code class outlined in the RPT online help (Extending Rational Performance Tester Functionality -> Custom Code Examples -> Retrieving the IP address of a Virtual user) that you can add to your test/schedule that will obtain the IP address