Faculty recruitment talk

1
Performance 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
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-sensitiv
  e 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

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

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

• 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).

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

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.

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.

17
Performance 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.

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..)
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.

23
Case 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
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