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

More documents

Recommendations

Info

Set Properties Set Properties Set Properties 116 CHAPTER 5. BENCHMARKING OF EVENT-BASED SYSTEMS Scenario I OrderQueue 1 Pub Sub … OrderQueue n Pub Sub Pub ConfQueue 1 Sub … ConfQueue n Pub Sub Topics Other Queues SM 1 DC 1 Recv SM n DC n Recv DC 1 SM 1 Recv DC n SM n Recv Scenario II Other Topics Incoming Order Topic Order Confirmation Topic Pub Pub Sub Sub Pub Pub Sub Sub (DC=1) (DC=n) (DC=1) (DC=n) Selectors (SM=1) (SM=n) (SM=1) (SM=n) Selectors Recv Recv Recv Recv SM 1 … SM n DC 1 … DC n DC 1 … DC n SM 1 … SM n Scenario III Message Bus Pub Pub Pub Pub Sub Sub Sub Sub (DC=1) (T=Order) (DC=n) (T=Order) (SM=1) (T=Conf.) (SM=n) (T=Conf.) (DC=1) (T=Order) (DC=n) (T=Order) (SM=1) (T=Conf.) (SM=n) (T=Conf.) Selectors Recv Recv Recv SM 1 … SM n DC 1 … DC n DC 1 … DC n SM 1 … SM n Figure 5.32: Considered Scenarios • Scenario II (Pub/Sub with Multiple Topics): For each message type, a separate topic is used, i.e., the TD configuration parameter is set to MessageType (cf. Table 5.12). • Scenario III (Pub/Sub with Message Bus): One topic is used for all messages, i.e., the TD configuration parameter is set to Central (cf. Table 5.12). The three scenarios differ mainly in terms of the flexibility they provide. While Scenario I is easy to implement given that no properties or selectors are necessary, it requires a reconfiguration of the MOM server for each new location or message type since new queues have to be set up. In contrast, Scenarios II and III, which only use topics, provide more flexibility. In Scenario II, a reconfiguration of the MOM server is necessary only when introducing new message types. Scenario III doesn’t require reconfiguration at all since a single topic (message bus) is used for communication. In addition, Scenarios II and III support one-to-many communication while the queue-based interactions in Scenario I are limited to one-to-one communication. One-to-many communication based on pub/sub allows to easily add additional message consumers, e.g., to maintain statistics about orders. On the other hand, the use of a limited number of topics in Scenarios II and III degrades the system scalability. As shown in the next section, the jms2009- PS benchmark allows to evaluate the trade-offs that different configurations provide in terms of flexibility, performance and scalability.
5.4. CASE STUDY II: JMS2009-PS 117 CPU Utilization 25 20 15 10 5 I II III CPU Utilization 100 80 60 40 20 I II III 0 50 100 150 200 0 200 400 600 800 BASE BASE Scenario Max Load CPU/BASE Avg. Dlv. Latency (ms) I 720 0.077 123 II 125 0.168 1587 III 63 0.147 3235 Figure 5.33: Experimental Results 5.4.3 Experimental Results Figure 5.33 presents the experimental results for the three scenarios described above. It shows the CPU utilization for increasing workload intensities (BASE), the maximum load that can be sustained by each scenario, the CPU time per unit of the BASE parameter and the average message delivery latency. The results show the scalability and performance of the three configurations as well as their costs in terms of CPU consumption. Scenario I scales up to BASE 720 and exhibits the lowest message delivery latency (123ms). The flexibility provided by Scenario II and III comes at the cost of much worse scalability and performance. The maximum load that can be sustained in Scenario II and Scenario III is respectively 6 and 12 times lower than that in Scenario I. Similarly, the average message delivery latency is about 13 times higher for Scenario II compared to Scenario I and about 26 times higher for Scenario III. Thus, the flexibility provided by Scenario II and III comes at a high price. This is due to two reasons: 1. The use of selectors leads to roughly two times higher CPU processing time per message (see Figure 5.33). 2. The use of topics for communication leads to synchronization delays. Comparing Scenarios II and III reveals that the selector complexity in this case does not have a significant impact on the CPU processing time per message. What is much more significant is the number of topics used for communication. The single topic in Scenario III clearly leads to a scalability bottleneck and explosion of the message delivery latency. In the third scenario, the throughput was limited by the performance of a single CPU core. Overall, the results show that topic-based communication using selectors is much more expensive than queue-based communication and, depending on the number of topics used, it limits the scalability of the system. We demonstrated how, by using jms2009-PS, the performance and scalability of different messaging workloads and configuration scenarios can be quantified. The high configurability of the benchmark allows us to tailor the workload to the user’s requirements by customizing it to resemble a given application scenario. The user can then evaluate alternative ways to implement message communication in terms of their overhead, performance and scalability.
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:
Page 53 and 54:
Page 55 and 56:
Page 57 and 58:
4.2. PERFORMANCE MODELING PATTERN 4
Page 59 and 60:
Page 61 and 62:
Page 63 and 64:
Page 65 and 66:
Page 67 and 68:
Page 69 and 70:
Page 71 and 72:
Page 73 and 74:
Page 75 and 76:
Page 77 and 78:
Page 79 and 80: 4.2. PERFORMANCE MODELING PATTERN 6
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 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: 5.4. CASE STUDY II: JMS2009-PS 115
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?