Title: Faculty recruitment talk
1Performance Analysis of a Middleware
Demultiplexing Pattern
Aniruddha Gokhale a.gokhale_at_vanderbilt.edu Dept.
of EECS, Vanderbilt University, Nashville, TN
Jeff Gray gray_at_cis.uab.edu Dept. of CIS Univ.
of Alabama at Birmingham Birmingham, AL
Swapna Gokhale U. Praphamontripong ssg_at_engr.uconn
.edu Dept. of CSE Univ. of Connecticut,
Storrs, CT
CSR CNS-0406376, CNS-0509271, CNS-0509296,
CNS-0509342
2Outline
- Introduction and Motivation
- Overview of event-driven systems
- Overview of Reactor pattern
- Performance analysis methodology
- Illustrations
- Conclusions and future research
3Distributed Performance Sensitive Software
Systems
- Military/Civilian distributed performance-sensitiv
e software systems - Network-centric larger-scale systems of
systems - Stringent simultaneous QoS demands
- e.g., dependability, security, scalability,
thruput - Dynamic context
4Trends 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
5Trends 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
6Outline
- Introduction and Motivation
- Overview of event-driven systems
- Overview of Reactor pattern
- Performance analysis methodology
- Illustrations
- Conclusions and future research
7Overview 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
8Overview 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
9Outline
- Introduction and Motivation
- Overview of event-driven systems
- Overview of Reactor pattern
- Performance analysis methodology
- Illustrations
- Conclusions and future research
10Overview 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
11Reactor 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
12Outline
- Introduction and Motivation
- Overview of event-driven systems
- Overview of Reactor pattern
- Performance analysis methodology
- Illustrations
- Conclusions and future research
13Characteristics of Reactor-based System
- 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 N1 and of type two is N2. - Event arrivals are Poisson for type one and type
two events with rates l1 and l2. - Event service time is exponential for type one
and type two events with rates m1 and m2. - In a snapshot, events are serviced
non-deterministically (in no particular order). -
14Performance 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
15Performance 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.
16Performance 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.
17Performance Model (contd..)
- 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.
18Outline
- Introduction and Motivation
- Overview of event-driven systems
- Overview of Reactor pattern
- Performance analysis methodology
- Illustrations
- Conclusions and future research
19Case 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
20Case 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.
21Case 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
22Case Study (contd..)
Expt. I Impact of buffer capacity
Arrival rates, l1 l2 0.4/sec, Service rates,
m1 m2 2.0/sec
Measure Buffer Space Buffer Space Buffer Space Buffer Space
Measure N1 N2 1 N1 N2 1 N1 N2 5 N1 N2 5
Measure 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.
- 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.
23Case Study (contd..)
Expt. II Sensitivity analysis
Response time of SMS 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.
-
Response time of Email service
24Outline
- Introduction and Motivation
- Overview of event-driven systems
- Overview of Reactor pattern
- Performance analysis methodology
- Illustrations
- Conclusions and future research
25Conclusions 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