Performance Analysis of a Middleware Demultiplexing Pattern

1. Performance Analysis of a Middleware Demultiplexing Pattern Aniruddha Gokhale a.gokhale@vanderbilt.edu Dept. of EECS, Vanderbilt University, Nashville, TN Jeff Gray gray@cis.uab.edu Dept. of CIS Univ. of Alabama at Birmingham Birmingham, AL Swapna Gokhale U. Praphamontripong ssg@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-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 • 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 Reactor Event Handler * handle_events() register_handler() remove_handler() dispatches handle_event () get_handle() * owns Handle * notifies handle set <<uses>> Concrete Event Handler A Concrete Event Handler B Synchronous Event Demuxer handle_event () get_handle() handle_event () get_handle() select () 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 : Main Program : Concrete : Reactor : Synchronous Event Handler Event Demultiplexer Con. Event Events register_handler() Handler get_handle() Handle handle_events() Handles select() event handle_event() Handles service() • 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 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 A2 A1 N2 N1 B2 B1 Sn1 Sn2 S2 S1 Sr2 Sr1 StSnpSht (a) (b) T_ProcSnp2 T_StSnp1 T_StSnp2 SnpInProg2 SnpInProg1 T_ProcSnp1 T_EnSnp2 T_EnSnp1 • 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..) A2 A1 N2 N1 B2 B1 Sn1 Sn2 S2 S1 Sr2 Sr1 StSnpSht (a) (b) T_ProcSnp2 T_StSnp1 T_StSnp2 SnpInProg2 SnpInProg1 T_ProcSnp1 T_EnSnp2 T_EnSnp1 • 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..) A2 A1 N2 N1 B2 B1 Sn1 Sn2 S2 S1 Sr2 Sr1 StSnpSht (a) (b) T_ProcSnp2 T_StSnp1 T_StSnp2 SnpInProg2 SnpInProg1 T_ProcSnp1 T_EnSnp2 T_EnSnp1 • 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 • 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