Table of Contents
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.
Let's start with a Figure that is worth a thousand words.
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
to the target system. More details about
architecture cen be found in the next section. For now, just remember that
Generator specifies HOW the messages are sent.
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.
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
. 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 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
The procedure of sending the messages is carefully monitored by the reporting facility of
PerfCake. The metrices are implemented using
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 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
can valide its content.
More details about individual parts of the application can be found in the later sections.