Performance Modeling and Benchmarking of Event-Based ... - DVS
Performance Modeling and Benchmarking of Event-Based ... - DVS
Performance Modeling and Benchmarking of Event-Based ... - DVS
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
4.2. PERFORMANCE MODELING PATTERN 59<br />
Pattern 6: Request Controlled Pull I<br />
Timer<br />
1‘Sleep!<br />
T3<br />
Trigger<br />
Store<br />
1‘<strong>Event</strong>!<br />
1‘<strong>Event</strong> 1‘<strong>Event</strong> 1‘<strong>Event</strong> 1‘<strong>Event</strong><br />
Producer<br />
T1<br />
Broker<br />
T2<br />
Consumer<br />
T2-I: Pull <strong>Event</strong><br />
T3-I: Consumer is ready<br />
Broker<br />
<strong>Event</strong><br />
Trigger Store<br />
Trigger<br />
T2-II: Go to sleep<br />
Broker<br />
Trigger<br />
1<br />
1<br />
1<br />
1<br />
1<br />
Consumer<br />
<strong>Event</strong><br />
Timer<br />
Sleep<br />
Consumer<br />
<strong>Event</strong><br />
Timer<br />
Sleep<br />
1<br />
T3-II: Wake up<br />
1<br />
1<br />
1<br />
Trigger Store<br />
Trigger<br />
Trigger Store<br />
Trigger<br />
Figure 4.14: St<strong>and</strong>ard Pull Patterns<br />
Characteristics<br />
• Pull-based communication on dem<strong>and</strong><br />
• Resource modeling (number <strong>of</strong> service places)<br />
Example<br />
An event consumer connects frequently to a broker to check whether notifications are waiting.<br />
If yes, the consumer downloads one <strong>of</strong> them, closes the connection <strong>and</strong> processes the event<br />
notification. As soon as the event has been processed the consumer connects again to the broker<br />
to pull the next event. If no event is available, the consumer closes the connection <strong>and</strong> waits for<br />
a specified period <strong>of</strong> time before pursuing the next pull attempt.<br />
Description<br />
This scenario differs mainly from the previous ones in that the pull attempt <strong>of</strong> the consumer is<br />
not only controlled by time but also by the availability <strong>of</strong> the consumer. The consumer tries<br />
to pull the next event as soon as he is ready, i.e. after the last event was processed. Only if<br />
no further event is available at the depository <strong>of</strong> the broker, the consumer disconnects <strong>and</strong> the<br />
next connection is triggered after a specified time interval.<br />
This behavior is reflected in transitions 2 & 3. When the consumer has processed an event,<br />
the <strong>Event</strong> token is transformed by transition 3-I to a Trigger token. Next, transition 2 is fired.