Rational Performance Test Server overview

The IBM® Rational® Performance Test Server has many features and a complex architecture.

Features in brief

Integration Tester is a rich, scripting-free environment for developing automatic tests for SOA and all messaging technology projects.

Rational Performance Test Server extends this functionality to enable users to:

  • Orchestrate® a large number of events across multiple computers.
  • Change the load generated by those multiple computers automatically.
  • Capture key performance indicators from the execution of these tests.
  • Capture key performance indicators from other items of infrastructure impacted by the tests.
  • Examine the results using powerful flexible charting.
  • Compare current results with past results from the same test.
  • Compare any results with any other result from other tests.
  • Embed these charts in reports.
  • Save the charts for sharing with colleagues.
  • Solving real world problems

A variety of real problems can be solved with the performance testing features included in Rational Performance Test Server, including:

Soak Tests Running a repetitive test over and over, monitoring CPU and memory utilization of the processes exercised by the test.
Load Tests Changing the load on the system to establish how it behaves under different load conditions.
Stress Tests Taking the load on the system to extreme levels, and ensuring that it does not develop any untoward side effects.

Deploy system statistics probes to monitor key components of the infrastructure, in particular the CPU and memory utilization of individual processes, and of any computers upon which the system under test depends.

Soak tests

Soak tests can generate a lot of information because they run for a long time. Longer summary intervals will avoid filling the database with an unnecessary level of detail. Increased intervals on probe configurations can be used for the same reason.

The Constant Growth load profile can be used with a zero increment to provide a constant load. If a varying load is required, use the Externally Defined load profile together with a test data set.

Load tests

Load tests subject the system to realistic loads (current and anticipated). It is important to subject the system to realistic loads (for example, a pension system might have 10,000 users around the world, but all users are unlikely to access the system at the same time). Conversely, a concert ticket system might be idle most of the time, but for a few hours (when tickets first go on sale) the number of users could far exceed even the total number of tickets available. This last example may be considered a stress test.

An Externally Defined load profile offers the best opportunity for controlling the load presented to the system over time.

Stress tests

Stress tests help ensure that the system fails gracefully under extreme loads and does not develop any unrequired side effects (for example, memory leaks, excessive time-outs, and so on).

Architecture

Note the following about network connectivity and deployment:

  • An Rational Integration Tester agent must be installed on every computer that runs a probe or a test engine instance to manage these processes (that is, launching them when required and shutting them down when they are no longer needed).
  • Every computer that runs an agent must be able to connect to the database.
  • The performance test controller computer must be able to contact the database and the agents.
  • Computers used within a test will need to have their clocks synchronized, this can be achieved using NTP.
  • Results database

The results database is essential because it stores all of the historical data for Rational Performance Test Server. The connection is JDBC-based, requiring a single user ID with its own schema, and all results are permanently stored for later analysis. For more information about supported databases and how they are created, refer to Configuring the project results database.

Performance test controller

This is Rational Integration Tester running to control the execution of performance tests including local and remote agents and probes. A special licence is required in order for Rational Integration Tester to act in this way, otherwise it will function as Rational Integration Tester with no performance functionality.

The controller may be run by means of the Rational Integration Tester GUI, or it may be run on the command-line.

Rational Integration Tester

Rational Performance Test Server includes all of the same functionality as Rational Integration Tester, with the addition of performance testing. This means that Rational Performance Test Server can be used to create functional tests that are executed as part of a performance test. Additionally, an external Rational Integration Tester installation may be used to create test projects that are used in performance tests using Rational Performance Test Server.

Rational Integration Tester Agent

An Rational Integration Tester Agent is a Java™ process that is used by the Performance Test Controller to start test engines and probes. An agent may be installed on the local computer or on a remote server. Communication between the agent and other components uses the HTTP protocol.

Test engine

A test engine is an instance of the Rational Integration Tester engine, started by an agent, that is executing a test. Test results are stored directly into the results database by means of a JDBC connection. Multiple test engines can be configured to run from a single agent, which allows for multiple distributed tests to be executed concurrently using a single agent.

Probe

A probe is a Java program that captures performance data that is external to the Rational Performance Test Server environment. Probes run during performance tests to measure the impact of functional and load tests on the IT infrastructure. For example, a Integration Tester test sends high volumes of message traffic to a messaging or web server. A probe would be used to collect statistics on the receiving servers and processes. This data can then be analyzed along with messaging data to assess how well the infrastructure can cope with the load. More than one probe may be run from a single agent process.

Probes write their results, as a set of counters, directly to the results database by means of a JDBC connection.

For more information about probes, refer to Deploying probes.


Feedback