Faculty recruitment talk - PowerPoint PPT Presentation

Loading...

PPT – Faculty recruitment talk PowerPoint presentation | free to download - id: 844564-MmE0N



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Faculty recruitment talk

Description:

Performance Analysis of a Middleware Demultiplexing Pattern Aniruddha Gokhale a.gokhale_at_vanderbilt.edu Dept. of EECS, Vanderbilt University, Nashville, TN – PowerPoint PPT presentation

Number of Views:37
Avg rating:3.0/5.0
Slides: 26
Provided by: Aniru1
Learn more at: http://gray.cs.ua.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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
About PowerShow.com