Performance Analysis of a Middleware Demultiplexing Pattern

Performance Analysis of a Performance Analysis of a Middleware Demultiplexing Middleware Demultiplexing

PatternPatternAniruddha Gokhale

[email protected]

Dept. of EECS, Vanderbilt University,

Nashville, TN

Swapna Gokhale U.

[email protected]

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

mailto:[email protected]




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





Illustrations


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





Illustrations


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


Concrete Event Handler B


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





Illustrations


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




(b)

17

Performance Model (contd..)

N1A1

B1

Sn1

S1

Sr1

N2A2

B2

Sn2

S2

Sr2

(a)

StSnpSht




(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





Illustrations


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


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


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





Illustrations


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

Documents

Performance Analysis of a Middleware Demultiplexing Pattern