performance analysis of the reactor pattern in network services
DESCRIPTION
Performance Analysis of the Reactor Pattern in Network Services. Swapna Gokhale [email protected] Asst. Professor of CSE, University of Connecticut, Storrs, CT. Aniruddha Gokhale [email protected] Asst. Professor of EECS, Vanderbilt University, Nashville, TN. Jeff Gray - PowerPoint PPT PresentationTRANSCRIPT
Performance Analysis of the Performance Analysis of the Reactor Pattern in Network Reactor Pattern in Network
ServicesServicesAniruddha Gokhale
Asst. Professor of EECS, Vanderbilt
University, Nashville, TN
Swapna Gokhale [email protected]
Asst. Professor of CSE, University of
Connecticut, Storrs, CT
Presented at PMEO-PDS Workshop, IEEE IPDPSRhodes, Greece
April 29, 2006
Work supported by collaborative grant from NSF CSR-SMA Program
Jeff Gray [email protected]
Asst. Professor of CISUniv. of Alabama,
BirminghamBirmingham, AL
2
Problem Statement: Estimating Performance Characteristics of Network Services 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
Provider Edge (PE)
Provider Edge (PE)
Provider Edge (PE)VR
VR
VR
VR
CE
CE
CE
VR
VR
VR
VR
CE
CE
CE
VR
VR
VR
VR
CE
CE
CE
CE
CE
Provider Edge (PE)VR
VR
VR
VR
Level 2 Service Provider
Backbone 1
Provider Edge (PE) VR
VR
VR
VR
Level 1 Service Providers
Provider Edge (PE) VR
VRVR
Backbone 2
VRVR
VR
CE
CE
CE
CE
CE
CE
CE
VP
N1
VP
N2
VP
N3
VP
N1
VP
N2
VP
N3
Virtual Router
FirewallMultiple tunnels to customer edge or virtual routers
Multiple tunnels to backbone or virtual routers
Level 1 Service Providers
• .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
Network services need support for efficient (de)-multiplexing, dispatching and routing/forwarding
3
Solution Approach: Middleware Performance Analysis using Stochastic Reward Nets
• 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).
N1 N2A1 A2
B1 B2
Sn1 Sn2
S2S1
Sr1 Sr2
StSnpSht
SnpShtInProg
T_SrvSnpSht T_EndSnpSht
(a) (b)
Transition
Place
Immediate transition
Inhibitor arc
Token
4
Goal: Performance Analysis of Reactor Pattern in VR
The Reactor architectural pattern allows event-driven applications to demultiplex & dispatch service requests that are delivered to an application from one or more clients.
• 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
•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
Provider Edge (PE)VR
VR
VR
VR
CE
CE
CE
VP
N1
5
Modeling VR Capabilities in a Reactor
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
• 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 1 and of type two is 2.
• Event arrivals are Poisson for type one and type two events with rates l1and l2resp.
• Event service time is exponential for type one and type two events with rates m1and 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: -Time taken to service the incoming event. -Bounded response time for real-time systems.
7
Modeling the Reactor using SRN (1/2)
• 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.
N1 N2A1 A2
B1 B2
Sn1 Sn2
S2S1
Sr1 Sr2
StSnpSht
SnpShtInProg
T_SrvSnpSht T_EndSnpSht
(a) (b)
Event arr.
Service queue
Servicing the event
Drop events on overflow
Prioritized service
Service completion
8
Modeling the Reactor using SRN (2/2)
N1 N2A1 A2
B1 B2
Sn1 Sn2
S2S1
Sr1 Sr2
StSnpSht
SnpShtInProg
T_SrvSnpSht T_EndSnpSht
(a) (b)
• 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:l11secl2/sec, m12secm22/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
0.8
1
1.2
1.4
1.6
1.8
2
2.2
2.4
0.4 0.6 0.8 1 1.2 1.4 1.6 1.8
Lambda_1
Res
po
nse
Tim
e
R1-Pess
R1-Sim
R1-Opt
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:l11secl2/sec, m12secm22/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 #10.8
1
1.2
1.4
1.6
1.8
2
0.4 0.6 0.8 1 1.2 1.4 1.6 1.8
Lambda_1
Res
po
nse
Tim
e
R2-Pess
R2-Sim
R2-Opt
11
Next Steps: Addressing Variability in Middleware
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
Although middleware provides reusable building blocks that capture commonalities, these blocks and their compositions incur variabilities that impact performance in significant ways.
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
Reactor
event demultiplexing strategy
event handling strategy
single threaded
thread pool
select poll WaitForMultipleObjects
Qt Tk
12
Composed System
Next Steps: Model-driven Performance Analysis of Middleware-based Network Services
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
Applying design-time performance analysis techniques to estimate the impact of variability in middleware-based DPSS systems
Invariant model of a
pattern
Refined model of a
patternvariability variabilityweave weave
Refined model of a
pattern
Refined model of a
pattern
Refined model of a
pattern
Refined model of a
pattern
Refined model of a
pattern
Refined model of a
patternworkload
workloadsystem
13
MDE Tool Developer (Metamodeler)
Application Developers (Modelers)
Technology Enabler: Generic Modeling Environment
www.isis.vanderbilt.edu/Projects/gme/default.htm
“Write Code That Writes Code That Writes Code!”
Decorator Decorator
GModel GMeta
CORE
MetamodelXML
Paradigm Definition
Storage Options… DB #nDB #1 XML …
UML / OCL
COM
COMCOM
XML
XML
ODBC
ConstraintManagerBrowser
Translator(s)Add-On(s)
GME Editor
GME Architecture
Goal: Correct-by-construction distributed systems
14
Leveraging Our Existing Solution: CoSMIC
Component
ResourceRequirements
Impl
Impl
Impl
Properties
Component Assembler
Component Assembly
Component Component
Component Component
Component Package
Component Assembly
Component Component
Component Component
Component Assembly
Component Component
Component Component
(1) d
evel
ops
(2) assembles
(3) packages
(4) c
onfig
ures
(6) deployment
Assembly
DeploymentApplication
Assembly
Assembly
CoSMIC
(8) re
configu
ratio
n &
repla
nnin
g
Analysis & Benchmarking
packaging
asse
mbl
y
specification
configuration
plan
ning
feedback
(7) analysis & benchmarking
(IDM
L &
PIC
ML)
(PICML)
(PIC
ML)
(OC
ML,
QoS
ML)
(Cadena & BGML)
DAnCE Framework
(5) planning
Component Developer
RACE Framework
),...,( 21 nxxxfy
Deployment Planner
Component Packager
Component Configurator
Systemanalyzer
ComponentDeployer
(9) design
feedback
CoSMIC tools e.g., PICML used to model application components Captures the data model of the OMG D&C specification Synthesis of static deployment plans for distributed applications New capabilities being added for QoS provisioning (real-time, fault tolerance)
CoSMIC can be downloaded at www.dre.vanderbilt.edu/cosmic
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)
Questions?