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

More documents

Recommendations

Info

54 CHAPTER 4. PERFORMANCE ENGINEERING OF EVENT-BASED SYSTEMS Pattern 4: Time Controlled Pull I Timer 1‘Event 1‘Event 1‘Event 1‘Event Producer T1 Broker T2 Consumer T2-I: Pull Event T2-II: Go back to sleep Broker Event Timer Trigger 1 1 1 1 Consumer Event Timer Trigger Timer Trigger 1 1 Timer Trigger Figure 4.12: Time-Controlled Pull Pattern Characteristics • Pull-based communication • Time controlled behavior: the consumer connects frequently to the broker to pull one event after a certain time interval. Example An event consumer connects frequently to a broker to check whether notifications are waiting. If yes, he downloads exactly one of them to process it. Afterwards, the consumer closes the connection and waits a specified period of time before reconnecting. A real world scenario represented by this pattern are Wireless-Sensor Networks (WSN). To save battery, the nodes are mostly disconnected. However, they connect frequently for a short moment to other nodes to exchange events and data. Description In modeling techniques such as QPNs, events are pushed by transitions from one place to another, e.g., after an event was served at one place, it is pushed to the next place. However, in scenarios like our example we are facing pull-based communication behavior and an approach is needed to reflect this in our models. Therefore we introduce a methodology how pull-based communication can be modeled using, e.g., QPNs. To model all aspects of our scenario, we presents additionally a way to implement time-controlled behavior. In our scenario the Consumer connects frequently to the Broker, tries to pull, if available, exactly one event and disconnect. To model this behavior, we need a timer which is responsible for establishing the connection. As shown in Figure 4.12 we implement the timer by adding a queuing place Timer (scheduling strategy: infinite server) and a new token color named Trigger, which triggers the establishment of the connections and the pull attempt after a certain time
4.2. PERFORMANCE MODELING PATTERN 55 interval. The interval between two connections is controlled by the service demand of the Trigger token on the Timer place (S T rigger,T imer ). Since the consumer disconnects immediately after the pull attempt there is no need to model connection times. We model the scenario as an endless loop composed of four phases. In the first phase, the consumer is disconnected and the Timer is processing the Trigger token. When the Timer has processed the Trigger token, the second phase starts and the connection is established. In the next phase, the consumer tries to pull an Event. Finally, the consumer closes the connection and we re-enter the first phase. In the following we illustrate our modeling approach in more detail: 1. System Initialization In the beginning, the connections is closed and one Trigger token is stored in the depository of the Timer place (end of the first phase). 2. Open and Close Connections When the Trigger token is available in the depository of the Timer, transition T2 is fired. Transition T2 implements the establishment of a connection (II. phase), the pull attempt (III. phase) and the disconnection (IV. phase). Two possibilities exist (see Figure 4.12): (a) The connection is established and the consumer pulls one Event from the Broker (T2-I ). (b) The connection is established, but no Event is available (T2-II ). In both cases, the connection has to be closed afterwards. This is implemented by adding the Trigger token to the Timer queue. When the connection is closed, we are back in the first phase. After t=S T rigger,T imer 2 , the Timer has processed the Trigger token and moves it to its depository. The next step is to enter the second phase and to open a connection to the broker again. Note T2-II should only be fired if no Event is available in the depository of the Broker. If an Event is available, T2-I has to be fired. Again, we have to face the limitation of standard QPNs that transition priorities are not supported. In this scenario, the easiest way is to define Firing Weight of T2-II the firing weights of the transitions so that Firing Weight of T2-I is close to zero, i.e. the possibility that T2-II is fired although a Event token exists is close to zero. QPN Definition Places: Place Type Description Producer S Publishes events. Broker Q Broker for all incoming events. Timer Q Timer place (scheduling strategy: Infinite Server). Consumer S Pulls events from broker. Colors: Color Event Trigger Description Represents the published event. Triggers pull commands. Init No. of Colors: Color Place Count Trigger Trigger Store 1 2 Since the Timer is using InfiniteServer as scheduling strategy, the response time of the queue for a token is equal to its service demand (and waiting time is zero).
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 67: 4.2. PERFORMANCE MODELING PATTERN 5
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 117 and 118: 5.2. CASE STUDY I: SPECJMS2007 103
Page 119 and 120:
5.2. CASE STUDY I: SPECJMS2007 105
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

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?