Performance Modeling and Benchmarking of Event-Based ... - DVS

92 CHAPTER 5. BENCHMARKING OF EVENT-BASED SYSTEMS
No. Msg.
9000
8000
7000
6000
5000
4000
3000
2000
1000
0
40 80 120 160 200 240 280
Base
a
b
c
d
Kbytes
20000
18000
16000
14000
12000
10000
8000
6000
4000
2000
0
40 80 120 160 200 240 280
Base
a
b
c
d
Figure 5.9: Horizontal Topology: # msg.
sent
Figure 5.10: Message Traffic in Kbytes
type and the bandwidth they use are scaled as a function of the BASE parameter. As evident
from the figure, when scaling the workload the proportions of the different types of messages
remain constant. This is expected since the relative weights of the various messaging styles used
by the workload should not depend on the scaling factor.
The sizes of the messages used in the various interactions have been chosen to reflect typical
message sizes in real-life MOM applications. Pub/sub messages are generally much smaller
than P2P messages due to the decoupled nature of the delivery mechanism. For every type
of message, SPECjms2007 generates messages with sizes chosen from a discrete distribution
with three possible values as shown in Table 5.5. There are two exceptions, the priceUpdate
message used in Interaction 4 and the statInfoSM message used in Interaction 5. The former
has a fixed size, while the latter has size between 4.7 and 24.78 KBytes with an average of
5.27 KBytes. Since statInfoSM messages contain sales statistics, their size is determined by
the rate at which items are sold in supermarkets which depends on the number of customers
visiting a supermarket per day and the average number of items sold per customer.
P2P transactional messages tend to be medium in size and P2P non-transactional range from
very small (≤ 1KBytes) to big (50 KBytes). Large messages are very rarely used in practice.
We decided to model three different messages sizes per message type based on a certain
probability:
• Small messages: up to 2 KBytes, probability 95 %
• Medium messages: up to 10 KBytes, probability of 4 %
• Large messages: up to 55 KBytes, probability of 1 %
Vertical Topology
The goal of the vertical topology is to exercise the ability of the system to handle increasing
message traffic through a fixed set of destinations. Therefore, a fixed set of physical locations
is used and the workload is scaled by increasing the rate at which interactions are executed.
Similar to the horizontal case, a single parameter BASE is used as a scaling factor. The following
rules are enforced:
1. |Ψ SM | = 10
2. |Ψ DC | = 2
3. |Ψ SP | = 5