Faculty recruitment talk

1
Performance Analysis of the Reactor Pattern in
Network Services
Aniruddha Gokhale a.gokhale_at_vanderbilt.edu Asst.
Professor of EECS, Vanderbilt University,
Nashville, TN
Swapna Gokhale ssg_at_engr.uconn.edu Asst.
Professor of CSE, University of Connecticut,
Storrs, CT
Jeff Gray gray_at_cis.uab.edu Asst. Professor of
CIS Univ. of Alabama, Birmingham Birmingham, AL
Presented at PMEO-PDS Workshop, IEEE
IPDPS Rhodes, Greece April 29, 2006 Work
supported by collaborative grant from NSF CSR-SMA
Program
2
Problem Statement Estimating Performance
Characteristics of Network Services at Design-time

• Network services need support for efficient
  (de)-multiplexing, dispatching and
  routing/forwarding

• .e.g., VPN Service provided by a virtual router
• Provides differentiated services to customers,
  e.g., prioritized service
• VPN setup messages must be efficiently (de)
  multiplexed, serviced and forwarded
• Need to estimate capacity of the system at
  design-time

• Standards middleware is increasingly being used
  to develop network services e.g., J2EE, .NET,
  CORBA, Web services
• Middleware frameworks incorporate elegant
  patterns-based building blocks
• Problem boils down to estimating performance of
  middleware

3
Solution Approach Middleware Performance
Analysis using Stochastic Reward Nets
Transition
Inhibitor arc
Place
Immediate transition
Token

• Stochastic Reward Nets (SRNs) are an extension to
  Generalized Stochastic Petri Nets (GSPNs) which
  are an extension to Petri Nets.
• Extend the modeling power of GSPNs by allowing
• Guard functions
• Marking-dependent arc multiplicities
• General transition probabilities
• Reward rates at the net level
• Allow model specification at a level closer to
  intuition.
• Solved using tools such as SPNP (Stochastic Petri
  Net Package).

4
Goal Performance Analysis of Reactor Pattern in
VR

• Customers send VPN setup messages to router
• VPN setup messages manifest as events at the VR
• VR must service these events (e.g., resource
  allocation) and honor the prioritized service, if
  any
• Accepted messages are forwarded
• Events could be dropped in overload conditions

The Reactor architectural pattern allows
event-driven applications to demultiplex
dispatch service requests that are delivered to
an application from one or more clients.

• 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

5
Modeling VR Capabilities in a Reactor

• Consider VPN service for two customer classes
• Reactor accepts and handles two types of input
  events
• Differentiated services for two classes
• Events are handled in prioritized order
• 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, resp.
• Event service time is exponential for type one
  and type two events with rates m1 and m2, resp.

Model of a single-threaded, select-based reactor
implementation
6
Performance Metrics of Interest for VR (i.e.,
Reactor)

• 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

7
Modeling the Reactor using SRN (1/2)
Event arr.
Drop events on overflow
Service queue
Prioritized service
Servicing the event
Service completion

• Models arrivals, queuing, and prioritized 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.
• Inhibitor arc from place S1 to transition Sr2
• - Offers prioritized service to an event
  of type one over event of type two.
• - Prevents firing of transition Sr2 when
  there is a token in place S1.

8
Modeling the Reactor using SRN (2/2)

• Process of taking successive snapshots
• Reactor waits for new events when currently
  enabled events are handled
• Sn1 enabled Token in StSnpSht Tokens in B1
  No Token in S1.
• Sn2 enabled Token in StSnpSht Tokens in B2
  No Token in S2.
• T_SrvSnpSht enabled Token in S1 and/or S2.
• SnpShtInProg Events being handled
• T_EndSnpSht enabled No token in S1 and S2
• Sn1 and Sn2 have same priority
• T_SrvSnpSht lower priority than Sn1 and Sn2

9
VR SRN Performance Estimates for Type 1

• SRN model solved using Stochastic Petri Net
  Package (SPNP) to obtain estimates of performance
  metrics.
• Parameter values l1 0.4 to 1.8/sec, l2
  0.4/sec, m1 2.0/sec, m2 2.0/sec.
• Two cases N1 N2 1, and N1 N2 5.

• Observations
• For lower arrival rates (type 1), response times
  tend to meet the lower bounds
• For higher arrival rates, response times tend
  towards the pessimistic bounds
• Simulation provides average case results that
  consistently lie between the two analytical
  bounds
• Simulation provides validation of our models
• Empirical benchmarking is also feasible

10
VR SRN Performance Estimates for Type 2

• SRN model solved using Stochastic Petri Net
  Package (SPNP) to obtain estimates of performance
  metrics.
• Parameter values l1 0.4 to 1.8/sec, l2
  0.4/sec, m1 2.0/sec, m2 2.0/sec.
• Two cases N1 N2 1, and N1 N2 5.

• Observations
• Simulation provides average case results that
  consistently lie between the two analytical
  bounds
• Not much effect on response time as a function of
  arrival rate of type 1

11
Next Steps Addressing Variability in Middleware
Although middleware provides reusable building
blocks that capture commonalities, these blocks
and their compositions incur variabilities that
impact performance in significant ways.

• Per Building Block Variability
• Incurred due to variations in implementations
  configurations for a patterns-based building
  block
• E.g., single threaded versus thread-pool based
  reactor implementation dimension that crosscuts
  the event demultiplexing strategy (e.g., select,
  poll, WaitForMultipleObjects

• Compositional Variability
• Incurred due to variations in the compositions of
  these building blocks
• Need to address compatibility in the compositions
  and individual configurations
• Dictated by needs of the domain
• E.g., Leader-Follower makes no sense in a single
  threaded Reactor

12
Next Steps Model-driven Performance Analysis of
Middleware-based Network Services
Applying design-time performance analysis
techniques to estimate the impact of variability
in middleware-based DPSS systems

• Build and validate performance models for
  invariant parts of middleware building blocks
• Weaving of variability concerns manifested in a
  building block into the performance models
• Compose and validate performance models of
  building blocks mirroring the anticipated
  software design of DPSS systems
• Estimate end-to-end performance of composed
  system
• Iterate until design meets performance
  requirements

Composed System
Refined model of a pattern
Refined model of a pattern
Invariant model of a pattern
Refined model of a pattern
Refined model of a pattern
Refined model of a pattern
weave
weave
variability
variability
Refined model of a pattern
Refined model of a pattern
system
13
Technology Enabler Generic Modeling Environment
Write Code That Writes Code That Writes Code!
GME Architecture
COM
COM
GME Editor
ConstraintManager
Browser
Translator(s)
COM
Add-On(s)
Metamodel
GModel
GMeta
XML
UML / OCL
CORE
Paradigm Definition
XML
ODBC
Goal Correct-by-construction distributed systems
www.isis.vanderbilt.edu/Projects/gme/default.htm
14
Leveraging Our Existing Solution CoSMIC
CoSMIC can be downloaded at www.dre.vanderbilt.edu
/cosmic

• CoSMIC tools e.g., PICML used to model
  application components
• Captures the data model of the OMG DC
  specification
• Synthesis of static deployment plans for
  distributed applications
• New capabilities being added for QoS provisioning
  (real-time, fault tolerance)

15
Concluding Remarks

• Network services are implemented using middleware
  building blocks
• Need to estimate performance early in development
  lifecycle
• Stochastic Reward Nets enables scalable
  intuitive performance analysis
• Goal is to use model-driven generative techniques
  to automatically synthesize performance models
  for network services
• Analysis for other dimensions of quality of
  service e.g., trustworthiness, dependability
• www.cse.uconn.edu/ssg (Swapna Gokhale)
• www.dre.vanderbilt.edu/gokhale (Aniruddha
  Gokhale)
• www.gray-area.org (Jeff Gray)

16
Questions?
17
VR SRN Performance Estimates
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
R 0.63/0.69 sec. 0.676 sec. (avg.) 0.79/0.83 sec. 0.800 sec. (avg.)
R2 0.65/1.10 sec. 0.72 sec. 0.82/1.33 sec. 0.86 sec.