Chapter 3. PerfCake Architecture

Table of Contents

3.1. PerfCake Architecture Overview
3.2. Run Info
3.3. Generators
3.3.1. Generators Architecture
3.3.2. Writing a New Generator
3.4. Message Senders
3.5. Receivers and Correlators
3.6. Sequences
3.7. Reporting
3.7.1. Reporting Architecture
3.7.2. Reporters
3.7.3. Destinations
3.7.4. Accumulators
3.8. Validators
3.8.1. Validators Architecture
3.8.2. Writing a New Validator

In this chapter we describe the inner architecture of PerfCake. First we inspect the overall design and then we delve deeper into the individual parts.

There is an easy concept that is good to bear in mind while working with PerfCake -- a single communication unit called a Message . PerfCake usually sends the message to the target system and measures the response time needed by the system being measured to provide a valid response. It is also the basic unit of the load that can be generated for the target system.

It is cruicial to understand the inner architecture when developing custom components. The lack of this knowledge can lead to wrong measurements and invalid performance results.

Let's investigate the architecture in more details.

3.1. PerfCake Architecture Overview

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

Figure 3.1. Architecture Overview

In the Figure 3.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.