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

More documents

Recommendations

Info

Broker Switch to 1 48 Event 1 CHAPTER 4. State PERFORMANCE A ENGINEERING OF EVENT-BASED SYSTEMS Not. T2-II Pattern 3: Standard Pub/Sub - Configurable No. of Subscribers 1‘Sub. 1‘Sub.A Init T0 Controller Configure Controlller T2 Creates the configured no. of notifications for each incoming Event. 1‘Event 1‘Event 1‘Notification 1‘Notification Producer T1 Publish Event Broker T3 Forward Event Consumers The Modi of Transition 2 T2 has four modi (T2-I to T2-IV), which a) implement states in the Controller place and b) create a configured number of notification tokens for each incoming event. T2-III: State A Controller State A Sub. B 1 1 1 1 1 Controller State A Sub. A Broker Not. Controller State A State B Broker Event 1 1 1 1 T2-I Switch to State B 1 1 Switch to State A T2-II Controller State A State B T2-IV: State B Controller State B 1 Sub. A 1 1 1 1 Controller State B Sub. B Broker Not. Figure 4.9: Standard Pub/Sub Pattern - Configurable No. of Subscribers 1‘Sub. 1‘Sub.A Characteristics Creates the configured no. of • Init 1 : n communication T0 Controller (one event is consumed T2 notifications by a configurable for each number incoming of consumers) Event. Configure Controlller • Dynamic number of notifications 1‘Event 1‘Event 1‘Notification 1‘Notification Example A Producer dynamic number of T1 event consumers Broker subscribe to a topic. T3 Publish Event Forward Event Description Consumers In complex and flexible models we need the possibility to scale the number of notifications easily. In these cases Pattern 2 is not applicable. As a consequence, we define Pattern 3 where the number of notifications per event can be configured by the token count. Pattern 3 is based on the underlying idea of Pattern 2 regarding the service demand. In contrast to Pattern 2, the user can configure the number of notifications for each event simply by adjusting the number of tokens named Subscriber in the system without modifying the
4.2. PERFORMANCE MODELING PATTERN 49 Subscriber 1‘Sub. State State A A 1‘Sub. A A 1‘Sub. 1‘Sub. Subscriber Subscriber A A 1‘Sub. 1‘Sub. A A Init Controller Init Init (a) Initialization Controller Controller State A State A Controller Controller Broker Broker Subscriber A Subscriber A State B 1‘State A State B 1‘State A 1‘State B 1‘State B 1‘Event 1‘Event Event Event Controller Controller 1‘State B 1‘State B 1‘State B 1‘State B 1‘Sub. B 1‘Sub. B 1‘Sub. A 1‘Sub. A Controller Controller Subscriber B Subscriber B 1‘Not. 1‘Not. Notification Notification Controller Controller Broker Broker 1‘State B 1‘State B 1‘State B 1‘State B 1‘Sub. B 1‘State B 1‘State B 1‘Sub. Controller 1‘Sub. 1‘State A B 1‘Sub. B 1‘Sub. 1‘State A B 1‘Sub. B Controller 1‘Sub. A 1‘Not. 1‘Sub. A 1‘Not. Controller Controller 1‘Not. 1‘Not. Broker Broker Broker Broker (b) Generate Notifications Figure 4.10: Example for Pattern 3 cardinality of the transitions. The number of Subscriber tokens can be set either by modifying the number of initial tokens in the system or by adjusting them dynamically at simulation time. The idea is that for an incoming event a notification is created for each Subscriber token and forwarded to the consumers. For this purpose we introduce an ordinary place Controller and define two colors, State A and State B, in QPNs. These colors are used to represent whether the Controller is either in state A or B, depending on the token stored in its depository. Further, for each subscriber, a token Subscriber A or Subscriber B depending on the state exists. An incoming Event triggers a state change from state A to B (or vice versa). As a response to an incoming Event the configured number of event notifications is generated. This is implemented by Transition 2-III / 2-IV (see Figure 4.9). As a reaction to a state change from A (B) to B (A), all n Subscriber A (B) tokens are transformed to n Subscriber B (A) tokens stored in the Controller and to n Notification tokens forwarded to the consumer. For a better understanding, we provide a detailed description of the different steps and states. The underlying transitions are illustrated in Figure 4.9. 1. System Initialization First, we configure the number of subscribers by setting the initialization number of Subscriber tokens n. These n tokens are then transformed by transition T0 to n Subscriber A tokens stored in the Controller place. This step is illustrated in Figure 4.10(a). Transition T0 is only fired once at system initialization time.
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 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 57 and 58: 4.2. PERFORMANCE MODELING PATTERN 4
Page 61: 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 113 and 114:
5.1. SPECJMS2007 - A STANDARD BENCH
Page 115 and 116:
5.2. CASE STUDY I: SPECJMS2007 101
Page 117 and 118:
Page 119 and 120:
Page 121 and 122:
Page 123 and 124:
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?