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

More documents

Recommendations

Info

90 CHAPTER 5. BENCHMARKING OF EVENT-BASED SYSTEMS The following equations characterize the message throughput of each DC: χ se DC,a = χ re DC,a = χ re DC,b = χ re DC,c = 0 χ se DC,b = λ 2 χ se DC,c = δ · λ 1 + λ 2 χ se DC,d = 3λ 1 · δ + 2λ 2 χ re DC,d = 3λ 1 · δ + λ 2 (ζ + 2) The HQ participate in Interactions 1, 2, and 5 as message consumer and in Interactions 3, 6, and 7 as message producer. The following equations characterize the message throughput of the HQ: χ re HQ,a = χ re HQ,b = χ se HQ,c = χ se HQ,d = 0 χ se HQ,a = λ 6 + λ 7 χ se HQ,b = λ 3 χ re HQ,c = λ 1 · |Ψ SM | + λ 2 · |Ψ DC | + λ 5 · |Ψ SM | χ re HQ,d = λ 2 · |Ψ DC | The detailed message throughput analysis presented above serves two main purposes. First, using the throughput equations, the user can assemble a workload configuration (in terms of number of locations and interaction rates) that stresses specific types of messaging under given scaling conditions. As a very basic example, the user might be interested in evaluating the performance and scalability of non-persistent pub/sub messaging under increasing number of subscribers. In this case, a mix of Interactions 6 and 7 can be used with increasing number of SMs. Second, the characterization of the message traffic on a per location basis can help users to find optimal deployment topology of the agents representing the different locations such that the load is evenly distributed among client nodes and there are no client-side bottlenecks. This is especially important for a messaging benchmark where the server acts as mediator in interactions and a significant amount of processing is executed on the client side. Horizontal Topology As mentioned earlier, the goal of the horizontal topology is to exercise the ability of the system to handle increasing number of destinations. To achieve this, the workload is scaled by increasing the number of physical locations (SMs, DCs, etc) while keeping the traffic per location constant. A scaling parameter BASE is introduced and the following rules are enforced: 1. |Ψ SM | = BASE 2. |Ψ DC | = ⌈ |Ψ SM | 5 ⌉ 3. |Ψ SP | = [0.4 · |Ψ SM |] 4. |Ψ HQ | = ⌈ |Ψ SM | 10 ⌉ 5. |Π| = |Ψ SM | 6. ρ = 5 |Π| 7. λ i , 1 ≤ i ≤ 7 are set as shown on Table 5.4 Figure 5.5 shows how the number of locations of each type is scaled as the BASE parameter is increased. The rates λ i at which interactions are initiated by participants are fixed so that the
5.1. SPECJMS2007 - A STANDARD BENCHMARK 91 180 Transactional Non-Transactional No. Locations 160 140 120 100 80 60 40 20 0 5 15 25 35 45 55 65 75 85 95 HQ SM SP DC 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% P2P Pub/Sub P2P Pub/Sub Base % Msg. % Kbytes Figure 5.5: # Locations for Horiz. Topology Figure 5.6: Horiz. Topology Message Mix Figure 5.7: Proportions of the Interactions based on Msg. Throughput Figure 5.8: Proportions of the Interactions based on Msg. Traffic in KBytes λ 1 λ 2 λ 3 λ 4 λ 5 λ 6 λ 7 1.53920154 2.13333333 6.00000000 3.37837837 11.54401154 11.38519924 9.23076923 Table 5.4: Interaction Rates for the Horizontal Topology traffic per location (and therefore also per destination) remains constant. In the Figures 5.7 and 5.8 the relative weights of the interactions is illustrated. They are set based on a detailed business model of the supermarket supply chain which captures the interaction interdependencies. This model has several input parameters (e.g. total number of product types, size of supermarkets, average number of items sold per week) whose values are chosen in such a way that the following overall target messaging mix is achieved as close as possible: • 50% P2P messages and 50% pub/sub • 50% of P2P messages persistent, 50% non-persistent • 25% of pub/sub messages persistent, 75% non-persistent The goal is to put equal weight on P2P and pub/sub messaging. Within each group the target relative weights of persistent vs. non-persistent messaging have been set according to the relative usage of these messaging styles in real-life applications. The criteria for what is a typical MOM application were defined based on input provided by the various participating vendors in the SPECjms working group including IBM, Sun, Oracle, BEA, Sybase and Apache. A comprehensive survey was conducted considering real-life customer applications and analyzing their workloads. Table 5.5(a) shows the resulting message mix in the horizontal topology. Figure 5.6 presents the same data in graphical form. Figures 5.9 and 5.10 show how the number of messages of each
Page 1:
Performance Modeling and Benchmarki
Page 4 and 5:
priorities. Finally, we validated o
Page 6 and 7:
4.3.4 Tool Extension . . . . . . .
Page 8 and 9:
5.7 Proportions of the Interactions
Page 11 and 12:
List of Acronyms Acronym λ t,k j A
Page 13 and 14:
Acronym SPEC-OSG SPE SPN SQL ST SUT
Page 15 and 16:
Chapter 1 Introduction 1.1 Motivati
Page 17 and 18:
PC Server 310 PC Server 310 PC Serv
Page 19 and 20:
1.3. APPROACH AND CONTRIBUTIONS OF
Page 21 and 22:
1.4. THESIS ORGANIZATION 7 • Stan
Page 23 and 24:
Chapter 2 Background In this chapte
Page 25 and 26:
2.1. EVENT-BASED SYSTEMS 11 is gene
Page 27 and 28:
2.2. TECHNOLOGY PLATFORMS OF EVENT-
Page 29 and 30:
Page 31 and 32:
Page 33 and 34:
Page 35 and 36:
2.3. INTRODUCTION TO QUEUEING PETRI
Page 37 and 38:
2.3. INTRODUCTION TO QUEUEING PETRI
Page 39 and 40:
Chapter 3 Related Work In this chap
Page 41 and 42:
3.2. BENCHMARKING OF EVENT-BASED SY
Page 43 and 44:
3.2. BENCHMARKING OF EVENT-BASED SY
Page 45 and 46:
3.4. CONCLUDING REMARKS 31 hierarch
Page 47 and 48:
Chapter 4 Performance Engineering o
Page 49 and 50:
4.1. MODELING METHODOLOGY FOR EBS 3
Page 51 and 52:
4.1. MODELING METHODOLOGY FOR EBS 3
Page 53 and 54: 4.1. MODELING METHODOLOGY FOR EBS 3
Page 55 and 56: 4.1. MODELING METHODOLOGY FOR EBS 4
Page 57 and 58: 4.2. PERFORMANCE MODELING PATTERN 4
Page 87 and 88: 4.3. EXTENSIONS OF QPNS 73 ,-).$%&'
Page 89 and 90: 4.4. CONCLUDING REMARKS 75 Without
Page 91 and 92: Chapter 5 Benchmarking of Event-Bas
Page 93 and 94: 5.1. SPECJMS2007 - A STANDARD BENCH
Page 103: 5.1. SPECJMS2007 - A STANDARD BENCH
Page 115 and 116: 5.2. CASE STUDY I: SPECJMS2007 101
Page 125 and 126: 5.3. JMS2009-PS - A PUBLISH /SUBSCR
Page 127 and 128: 5.3. JMS2009-PS - A PUBLISH /SUBSCR
Page 129 and 130: 5.4. CASE STUDY II: JMS2009-PS 115
Page 131 and 132: 5.4. CASE STUDY II: JMS2009-PS 117
Page 133 and 134: Chapter 6 Performance Modeling of E
Page 135 and 136: 6.2. MODELING SPECJMS2007 121 Scena
Page 137 and 138: 6.2. MODELING SPECJMS2007 123 BASE*
Page 139 and 140: 6.2. MODELING SPECJMS2007 125 1‘O
Page 141 and 142: 6.2. MODELING SPECJMS2007 127 Sc. 1
Page 143 and 144: 6.2. MODELING SPECJMS2007 129 Perce
Page 145 and 146: 6.2. MODELING SPECJMS2007 131 Serve
Page 147 and 148: 6.3. CONCLUDING REMARKS 133 the mod
Page 149 and 150: Chapter 7 Conclusions and Outlook W
Page 151 and 152: 7.1. ONGOING AND FUTURE WORK 137 JA
Page 153 and 154: 7.1. ONGOING AND FUTURE WORK 139 th
Page 155 and 156:
Bibliography [1] J. Abbott, K. B. M
Page 157 and 158:
BIBLIOGRAPHY 143 [29] BiCEP Researc
Page 159 and 160:
BIBLIOGRAPHY 145 [61] G. Cugola and
Page 161 and 162:
BIBLIOGRAPHY 147 [92] R. Henjes, M.
Page 163 and 164:
BIBLIOGRAPHY 149 [128] S. Kounev an
Page 165 and 166:
BIBLIOGRAPHY 151 [162] Object Compu
Page 167 and 168:
BIBLIOGRAPHY 153 [197] K. Sachs, S.
Page 169 and 170:
BIBLIOGRAPHY 155 [228] P. Tran, P.
Page 171:
Erklärung Hiermit erkläre ich, di
show all

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

Create successful ePaper yourself

Delete template?

Save as template?