Performance Study of Message Passing in an Event Service: Java RMI vs. TCP Sockets

1. Performance Study of Message Passing in an Event Service:Java RMI vs. TCP Sockets MSE Project PresentationPhase-I Laxminarayan Muktinutalapati(Lux) Department of Computing and Information Sciences Kansas State University

2. Overview • Introduction • Event service • Project Focus • Java RMI vs. TCP Sockets • Assumptions and Constraints …contd.

3. Overview …(2) • Software Requirements Specification • Size Estimates • Project Plan • Documentation

4. Introduction • Event based distributed systems • Programmed to operate in response to events • E.g.: Instant messaging, Stock-price tracking, etc. • Distributed event service developed independently in Java for the project

5. The Event Service • Distributed event service • Producer-Consumer pattern • Supports push model of event reception • Producers and Consumers decoupled • Event Notification Service (ENS) is the means of communication

6. Event Service …(2) • Function of Event Notification Service (ENS) • Deliver information regarding events published (by Producers) to those (Consumers) who are interested in the corresponding information • Consumers typically register interest in certain events with ENS

7. subscribe(event) Producer Consumer unsubscribe(event) push(event) push(event) Event Notification Service Event Service – Diagram

8. Project Focus • Time based measures – to determine efficiency of underlying mechanism used for message passing • Java RMI vs. TCP Sockets • Tests performed at varying loads…

9. subscribe(event) Producer Consumer unsubscribe(event) push(event) push(event) Event Notification Service Measurements • Time taken for each event: Ti = t1i + max { t2i= 1..n} t1i t2i

10. Java RMI vs. TCP Sockets • Equivalent to a choice between ease of use and performance • RMI inherits all the benefits from Java • Issues like object serialization handled by Java • Communication via sockets known to be considerably faster

11. Assumptions and Constraints • System operates on a complete network – every node connected to every other node • Predefined set of events the producers generate, which the consumers are familiar with • Network latency – negligible or no effect on results • Tests conducted to accommodate any other such factors (time of day, load on system, etc.)

12. Software Requirements Specification • To identify and define the requirements to aid in developing the proposed system • Overall description of the system is followed by a section that gives the specific requirements which discusses key functionality of the end product in adequate detail • This document shall evolve continually

13. Size Estimation • Based on Function Point Analysis (FPA) as outlined by IFPUG • Software measured in terms of user-level functionality – system broken down into smaller components based on functionality • Independent of technology used • Functional components carry weights which contribute to the final Function Point Count (FPC), which can be translated into a fair estimate of the size of the proposed system

14. Estimates Summary • Total Unadjusted Function PointsUFP = 51 • Value Adjustment FactorVAF = 1.0 • Final Function Point CountFPC = UFP * VAF = 51 • Language Factor for Java (LF): 53 • Estimated Source Lines of CodeSLOC = FPC * LF = 2703

15. Project Plan • Phase I: Requirements • Overview, SRS, Cost Estimate, Project Plan • December 18, 2002 • Phase II: Architecture • Formal Requirement Specification, Software Quality Assurance Plan, Architecture Design, Test Plan, Formal Technical Inspection • January 2003 • Phase III: Implementation • User manual, Source Code, Testing and Reliability Evaluation, Project Evaluation, References • February 2003

16. Documentation • The following documents, required for the Phase-I presentation are available online: • Overview Document • Software Requirements Specification • Cost Estimation • Project Plan • Engineering Notebook (Time log) URL - http://www.cis.ksu.edu/~lmu9988/MSE/P1

17. Thank You!