160 likes | 340 Views
Performance Analysis of the Reactor Pattern in Network Services. Swapna Gokhale ssg@engr.uconn.edu Asst. Professor of CSE, University of Connecticut, Storrs, CT. Aniruddha Gokhale a.gokhale@vanderbilt.edu Asst. Professor of EECS, Vanderbilt University, Nashville, TN. Jeff Gray
E N D
Performance Analysis of the Reactor Pattern in Network Services Swapna Gokhale ssg@engr.uconn.edu Asst. Professor of CSE, University of Connecticut, Storrs, CT Aniruddha Gokhale a.gokhale@vanderbilt.edu Asst. Professor of EECS, Vanderbilt University, Nashville, TN Jeff Gray gray@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
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
Solution Approach: Middleware Performance Analysis using Stochastic Reward Nets A2 A1 StSnpSht N2 N1 B2 B1 T_SrvSnpSht T_EndSnpSht Sn1 Sn2 S2 S1 SnpShtInProg Sr2 (a) (b) Sr1 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).
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
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 l1and l2, resp. • 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
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.
Modeling the Reactor using SRN (1/2) A2 A1 StSnpSht N2 N1 B2 B1 T_SrvSnpSht T_EndSnpSht Sn1 Sn2 S2 S1 SnpShtInProg Sr2 (a) (b) Sr1 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.
Modeling the Reactor using SRN (2/2) A2 A1 StSnpSht N2 N1 B2 B1 T_SrvSnpSht T_EndSnpSht Sn1 Sn2 S2 S1 SnpShtInProg Sr2 (a) (b) Sr1 • 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
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
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
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
Next Steps: Model-driven Performance Analysis of Middleware-based Network Services workload workload 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 Refined model of a pattern Invariant 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
Technology Enabler: Generic Modeling Environment Decorator Decorator Application Developers (Modelers) XML XML MDE Tool Developer (Metamodeler) … … DB #n DB #1 Storage Options “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
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 D&C specification • Synthesis of static deployment plans for distributed applications • New capabilities being added for QoS provisioning (real-time, fault tolerance)
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)