Upload
kristina-charles
View
230
Download
0
Tags:
Embed Size (px)
Citation preview
Performance Analysis of a Performance Analysis of a Middleware Demultiplexing Middleware Demultiplexing
PatternPatternAniruddha Gokhale
Dept. of EECS, Vanderbilt University,
Nashville, TN
Swapna Gokhale U.
Dept. of CSE Univ. of
Connecticut, Storrs, CT
Jeff Gray [email protected]
Dept. of CISUniv. of Alabama at
BirminghamBirmingham, AL
CSR CNS-0406376, CNS-0509271, CNS-0509296, CNS-0509342
2
Outline
Introduction and Motivation
Overview of event-driven systems
Overview of Reactor pattern
Performance analysis methodology
Illustrations
Conclusions and future research
3
Distributed Performance Sensitive Software Systems
Military/Civilian distributed performance-sensitive software systems
• Network-centric & larger-scale “systems of systems”• Stringent simultaneous QoS demands
• e.g., dependability, security, scalability, thruput• Dynamic context
Military/Civilian distributed performance-sensitive software systems
• Network-centric & larger-scale “systems of systems”• Stringent simultaneous QoS demands
• e.g., dependability, security, scalability, thruput• Dynamic context
4
Trends in DPSS Development Historically developed using low-
level APIs
Increasing use of middleware technologies
Standards-based COTS middleware helps to:– Control end-to-end resources &
QoS– Leverage hardware & software
technology advances– Evolve to new environments &
requirements
Middleware helps capture & codify commonalities across applications in different domains by providing reusable & configurable patterns-based building blocks
Examples: CORBA, .Net, J2EE, ICE, MQSeries
Developers must decide at design-time which blocks to use to obtain desired functionality and performance
5
Trends in DPSS Development (contd..)
Configuration parameters of patterns have profound influence on system performance.
Current methods of selecting patterns and their configurations is ad-hoc, error prone.
Performance analysis conducted after the system is built– Too late, too expensive to fix performance problems.
Design-time performance analysis of patterns and their composition necessary to avoid these pitfalls
6
Outline
Introduction and Motivation
Overview of event-driven systems
Overview of Reactor pattern
Performance analysis methodology
Illustrations
Conclusions and future research
7
Overview of Event-Driven systems
Software systems based on event-driven paradigm – Listens for service requests or events– Provides services in response to events– Requests issued by end users or other systems– System may be a component of a composition– Advantages: Evolvability and composability
Evolvability: – Separation of event demultiplexing and dispatching
from event handling
Composability: – Invoke service transparently without knowledge of
implementation
8
Overview of Event-Driven Systems
Event handling specific to a system
Codify common event demultiplexing and dispatching capabilities in event-driven systems in Reactor pattern
Design-time performance analysis of event-driven systems requires model of the Reactor pattern
Contribution: Performance model of a Reactor-based system based on the Stochastic Reward Net (SRN) paradigm
9
Outline
Introduction and Motivation
Overview of event-driven systems
Overview of Reactor pattern
Performance analysis methodology
Illustrations
Conclusions and future research
10
Overview of Reactor Pattern
The Reactor architectural pattern allows event-driven applications to demultiplex & dispatch service requests that are delivered to an application from one or more clients.
•Many networked applications are developed as event-driven programs
•Common sources of events in these applications include activity on an IPC stream for I/O operations, POSIX signals, Windows handle signaling, & timer expirations
•Reactor pattern decouples the detection, demultiplexing, & dispatching of events from the handling of events
•Participants include the Reactor, Event handle, Event demultiplexer, abstract and concrete event handlers
Handleowns
dispatches*
notifies**
handle set
Reactorhandle_events()register_handler()remove_handler()
Event Handler
handle_event ()get_handle()
Concrete Event Handler A
handle_event ()get_handle()
Concrete Event Handler B
handle_event ()get_handle()
SynchronousEvent Demuxer
select ()
<<uses>>
11
Reactor Dynamics
Registration Phase• Event handlers register themselves with the Reactor for an event type (e.g., input,
output, timeout, exception event types)• Reactor returns a handle it maintains, which it uses to associate an event type with the
registered handler
Snapshot Phase• Main program delegates thread of control to Reactor, which in turn takes a snapshot of
the system to determine which events are enabled in that snapshot• For each enabled event, the corresponding event handler is invoked, which services
the event• When all events in a snapshot are handled, the Reactor proceeds to the next snapshot
: Main Program : ConcreteEvent Handler
: Reactor : Synchronous Event
Demultiplexer
register_handler()
get_handle()
handle_events() select()
handle_event()
Handle
Handles
Handles
Con. EventHandler Events
service()
event
12
Outline
Introduction and Motivation
Overview of event-driven systems
Overview of Reactor pattern
Performance analysis methodology
Illustrations
Conclusions and future research
13
Characteristics of Reactor-based System
network
Single Threaded Reactor
Event Handler with
exponential service time m1
select-based event demultiplexer
Event Handler with
exponential service time m2
l2 Poisson arrival rate
l1 Poisson arrival rate
N1
N2
incoming events
•Single-threaded, select-based Reactor implementation
•Reactor accepts two types of input events, with one event handler registered for each event type with the Reactor
•Each event type has a separate queue to hold the incoming events. Buffer capacity for events of type one is 1 and of type two is 2.
•Event arrivals are Poisson for type one and type two events with rates l1and l2.
•Event service time is exponential for type one and type two events with rates m1and m2.
•In a snapshot, events are serviced non-deterministically (in no particular order).
14
Performance Metrics•Throughput:
-Number of events that can be processed -Applications such as telecommunications call processing.
•Queue length: -Queuing for the event handler queues. -Appropriate scheduling policies for applications with real-time requirements.
•Total number of events: -Total number of events in the system. -Scheduling decisions. -Resource provisioning required to sustain system demands.
•Probability of event loss: -Events discarded due to lack of buffer space. -Safety-critical systems. -Levels of resource provisioning.
•Response time: -Time taken to service the incoming event. - Important from user’s perspective, real-time systems.
15
Performance Model
Stochastic Reward Nets (SRNs) – Extension of PNs/GSPNs. Part A: Models arrivals, queuing, and service of events. •Transitions A1 and A2: Event arrivals.•Places B1 and B2: Buffer/queues.•Places S1 and S2: Service of the events.•Transitions Sr1 and Sr2: Service completions.•Inhibitor arcs: Place B1and transition A1 with multiplicity N1 (B2, A2, N2) - Prevents firing of transition A1 when there are N1 tokens in place B1.
N1A1
B1
Sn1
S1
Sr1
N2A2
B2
Sn2
S2
Sr2
(a)
StSnpSht
T_StSnp1 T_StSnp2T_ProcSnp2
T_ProcSnp1T_EnSnp1 T_EnSnp2
SnpInProg1 SnpInProg2
(b)
16
Performance Model (contd..)
Part B:•Process of taking successive snapshots•Non-deterministic service of events. •T_StSnp(i) enabled: Token in StSnpSht && Tokens in B(i) & no Token in S(i).•T_EnSnp(i) enabled: No token in S(i).•T_ProcSnp(i) enabled: Token in place S(i) and no token in other S(i)s.
N1A1
B1
Sn1
S1
Sr1
N2A2
B2
Sn2
S2
Sr2
(a)
StSnpSht
T_StSnp1 T_StSnp2T_ProcSnp2
T_ProcSnp1T_EnSnp1 T_EnSnp2
SnpInProg1 SnpInProg2
(b)
17
Performance Model (contd..)
N1A1
B1
Sn1
S1
Sr1
N2A2
B2
Sn2
S2
Sr2
(a)
StSnpSht
T_StSnp1 T_StSnp2T_ProcSnp2
T_ProcSnp1T_EnSnp1 T_EnSnp2
SnpInProg1 SnpInProg2
(b)
Reward rates:•Loss probability (Pr(#B(i) == N(i)))•Total number of events ((#B(i) + #S(i)))•Throughput (rate(“Sr(i)”))•Queue length ((#B(i))•Optimistic and pessimistic bounds on the response times using the tagged-customer approach.
18
Outline
Introduction and Motivation
Overview of event-driven systems
Overview of Reactor pattern
Performance analysis methodology
Illustrations
Conclusions and future research
19
Case Study
Software architecture in mobile handhelds
Needed to support applications such as email, web browsing, calendar management
Critical domains such as health care monitoring, emergency response systems
Exceptional performance essential
20
Case Study (contd..) Application mix in handhelds apt for event-
driven implementation– Appointments in the calendar, email may raise an
event in the midst of browsing– Important sensor data may be delivered via Short
Message Service (SMS)
Handheld with two services:– Email and SMS service – Implement the system with Reactor pattern
Performance concerns:– Response time of SMS notifications below an
acceptable threshold.– Probability of rejecting emails and SMS notifications
negligible.
21
Case Study (contd..)
Demonstrate the use of SRN model of Reactor-based system to guide selection of configuration options:– Event type #1: SMS notifications
– Event type #2: Email
Two experiments:– Impact of buffer capacity
– Sensitivity to arrival rates
Validate performance estimates obtained from SRN using simulation implemented in CSIM
22
Case Study (contd..)
Arrival rates, l1 = l2 = 0.4/sec, Service rates, m1 = m2 = 2.0/sec
Measure
Buffer Space
N1 = N2 = 1 N1 = N2 = 5
SRN CSIM SRN CSIM
T1 0.37/sec. 0.365/sec. 0.399/sec. 0.395/sec.
Q1 0.064 0.0596 0.12 0.115
L1 0.064 0.0024
R1,l 0.63 sec.0.676 sec.
(avg.)0.79 sec.
0.830 sec. (avg.)
R1,u 0.86 sec. 1.08 sec.
Expt. I: Impact of buffer capacity
•Loss probability significant when buffer size = 1, reduces for size = 5.•Throughput slightly lower when buffer size = 1.
•Estimates obtained from SRN close to simulation.•Average response time from simulation in between optimistic and pessimistic response times obtained from SRN.
23
Case Study (contd..)
0
0.5
1
1.5
2
2.5
3
0.5 0.7 0.9 1.1 1.3 1.5 1.7 1.9
lam1
Res
po
nse
tim
e
pessoptcsim
0
0.5
1
1.5
2
2.5
3
0.5 0.7 0.9 1.1 1.3 1.5 1.7 1.9
lam1
Res
po
nse
tim
e
pessoptcsim
Response time of SMS service
Response time of Email service
•Vary the arrival rate of SMS events. -- Remaining parameters same as before.
•Response time of SMS, Email service: -- Approaches pessimistic response time as arrival rate becomes higher. -- Actual response time of SMS events is higher than Email events. •Loss probabilities of SMS, Email service: -- Increases with arrival rate for SMS -- Unaffected for Email service
•Throughputs of SMS, Email service: -- Lags arrival rate for SMS -- Unaffected for Email service.
Expt. II: Sensitivity analysis
24
Outline
Introduction and Motivation
Overview of event-driven systems
Overview of Reactor pattern
Performance analysis methodology
Illustrations
Conclusions and future research
25
Conclusions and Future Research
Design-time performance analysis methodology for event-driven systems– SRN modeling paradigm.
Illustration of the methodology using case study of a handheld device
Performance analysis methodologies for other patterns such as the Proactor, Active Object and composition of patterns