Chapter 2. PerfCake Features

Table of Contents

2.1. PerfCake Architecture Overview
2.2. Performance scenario definition
2.2.1. XML scenario
Scenario structure
Sections of the scenario
2.2.2. DSL scenario
2.2.3. Scenario specified through API
2.2.4. IDE plugins
2.2.5. Filtering properties
2.3. Running PerfCake
2.3.1. Command line parameters
2.3.2. Running scenarios from Maven
2.3.3. Logging
2.3.4. Results Replay
2.3.5. Debug Agent
2.4. What to take care of during execution
2.5. Exit codes
2.6. Migrating scenarios to latest version
2.6.1. From v1.0 to v2.x
Migration steps
2.6.2. From v2.x to v3.x
Migration steps
Scenario conversion using XSLT
2.6.3. From v3.x to v4.x
Migration steps
2.6.4. From v4.x to v5.x
Migration steps
Scenario conversion using XSLT
2.6.5. From v5.x to v6.x
Migration steps
2.6.6. From v6.x to v7.x
Migration steps

2.1. PerfCake Architecture Overview

Let's start with a Figure that is worth a thousand words.

Figure 2.1. Architecture Overview


In the Figure 2.1, “Architecture Overview” , we can see the high level overview of PerfCake's architecture. There is always a single Generatorthat works like an engine in the performance test. The main purpose of the Generator is to specify how the messages are generated. The easiest case would be to send a message to the target system, wait for the response and measure the response time. However, this would not tell us anything about performance of the target system. What is more interesting is a load generated in many parallel threads as fast as possible.

The default generator implementation (DefaultMessageGenerator) has a queue of messages ready to be send by a Sender to the target system. More details about Generator architecture cen be found in the next section. For now, just remember that Generator specifies HOW the messages are sent.

A Sender represents a protocol specific "pump" of message to a target service or system under test. The protocols can be HTTP, REST, JMS, JDBC, SOAP, socket, file etc. The Sender is configured with a specific address for the given protocol. So the Sender tells WHERE TO send the messages.

A Message is the content of the smallest unit of load that is sent to the target system. So basically it says WHAT is sent.

For the ability to have different Message each time it is sent or to fill in some dynamic values, a sophisticated templating engine is used. Each message can be enriched ("oiled") with dynamic values. To provide the dynamic values, we can use a Sequence . This is a simple interface that returns another value in the row each time it is called.

Optionally, a response to the original request can be received through a separate message channel. This is where Receivers come at hand. A Receiver manages an "inflow" of responses to the original requests and passes them to a Correlator. The Correlator then matches the responses to the original requests based on some specific information (i.e. correlation ID) in both of the messages. A complete request-response cycle is then being measured.

The procedure of sending the messages is carefully monitored by the reporting facility of PerfCake. The metrices are implemented using Reporters. A Reporter accumulates single measurements of individual requests into meaningful values (e.g. throughput, memory usage, response time, service time, response time histogram, etc.) and waits for them to be "discharged" at specified intervals into a Destination. The Destination specifies where the measured results are stored (e.g. chart, CSV file, log file, database, etc.).

Finally, there are validators that prove the responses to be valid. Some system can start responding very fast under a heavy load, but just with a blunt overload warning. To prevent any such failure, a Validator can valide its content.

More details about individual parts of the application can be found in the later sections.