Sales Inventory Management System - CMU (ECE)

Loading...
Team 2:

Sales Inventory Management System Vamshi Ambati Myung-Joo Ko Ryan Frenz Cindy Jen

S04-17654-A Analysis of Software Artifacts

Team Members

Rfrenz Vamshi @andrew.cmu.edu @andrew.cmu.edu

Ryan Frenz

Vamshi Ambati

Mko1 Cdj @andrew.cmu.edu @andrew.cmu.edu

Cindy Jen

Myung-Joo Ko

http://www.ece.cmu.edu/~ece846/team2 2 Team2 Final Presentation

S04-17654-A Analysis of Software Artifacts

Introduction Baseline Application „ Fault Tolerance „ Real-time „ High Performance „ Conclusion „

3 Team2 Final Presentation

Baseline Application Jan 21 – Feb 13

S04-17654-A Analysis of Software Artifacts

Baseline Application „

Sales Inventory Management System

…

Menu-Based Client „

…

Sales/Purchasing Management „

…

Handle requests to create, view, or remove sales or purchase orders, respectively

User Management „ „

…

Login, create/view/remove Sales/Purchase Orders, Inventory, Users

Controls add/view/remove of users Login/logout

Inventory Management „

Add/view/create inventory

5 Team2 Final Presentation

S04-17654-A Analysis of Software Artifacts

Baseline Application Java-based, 3-tier application „ Middleware : EJB / Jboss „ OS : Linux (MS Compatible too) „ DB : MySql „ Deployment tool : Ant „

6 Team2 Final Presentation

S04-17654-A Analysis of Software Artifacts

Baseline Application „

Why Interesting? … Strong „

data integrity requirements

Data seen at any client must be accurate at any given time, regardless of other clients accessing/modifying it

Item No: 1 Qty: 100

Order No: 1 Item No: 1 Qty: 10 Salesperson

Complete Order ? Yes Item No: 1 Qty: 90

Administrator

7 Team2 Final Presentation

S04-17654-A Analysis of Software Artifacts

Baseline Architecture Client Tier

Middle Tier

Backend

User Management Client applications AddUser() ViewProfile() GetItemlist() GetItemDetail() PlacePurchaseOrder() GetPurchaseOrderlist() GetPurchaseOrderDetail() PlaceSalesOrder() GetSalesOrderlist() GetSalesOrderDetail() GetOperationId() LogIn() LogOut()

Inventory Management

Purchase Order Management

MySql

Database Sales Order Management

User Item SalesOrder PurchaseOrder

EJB Container Application Server (JBOSS) Naming Service (JNDI)

JDBC Remote Method Invocation Client applications Server application

Database

JNDI call

8

Team2 Final Presentation

S04-17654-A Analysis of Software Artifacts

Baseline Architecture Client Tier

Middle Tier

Backend EJB Container

SalesOrder RemoteHome

SalesServer Remote

SalesOrder HomeLocal

SalesOrder Local

Database

Sales OrderBean

Sales Order

Entity Bean Sales ServerBean Session Bean

4 EJB Patterns Container Managed Entity Beans with Session Beans Entity Beans Only

Bean Managed Entity Beans with Session Beans Session Beans Only

9 Team2 Final Presentation

Fault Tolerance + Baseline Feb 13 – March 16

S04-17654-A Analysis of Software Artifacts

Fault-Tolerance Goals „ „

„

Replicate Sales, Purchasing, Inventory, User, and Operations Servers Server modules are ‘stateless’ … we simply store a record of the last transaction in the database to prevent duplication in the case of a fault ‘Sacred’ Machine … Database, Replication Manager, FaultInjector 11 Team2 Final Presentation

S04-17654-A Analysis of Software Artifacts

FT-Baseline Architecture Client Tier

Middle Tier User Management

Client applications

Inventory Management Operation Tracking User Management

Inventory Management Operation Tracking

Backend

Primary Replica MySql

Purchase Order Management

Database

Sales Order Management

Sacred Machine

Backup Replica Fault Detector

Purchase Order Management Sales Order Management

Replication Manager

Application Server (JBOSS) Naming Service (JNDI)

KEY

JDBC Remote Method Invocation Client applications

Server application

Database

JNDI call

12

Team2 Final Presentation

S04-17654-A Analysis of Software Artifacts

Mechanisms for Fail-Over „

Fail-Over through exception handling

„

Fault-Detection through replication managerCrashed replica is restarted upon detection

„

Exceptions Caught: … … … … … …

NamingException „ JNDI is down (and consequently replica) RemoteException „ JNDI is still up but replica is down CreateException „ Any DB Problem (unavailable, duplicate create, etc) Create Exception Æ notify user (don’t fail over) Naming and Remote Æ retry with backup replica 13 Next request Æ start over, trying primary first Team2 Final Presentation

S04-17654-A Analysis of Software Artifacts

Mechanisms for Fail-Over „

Replica references are obtained at time of request

„

This allows for a simple fault-tolerance model

If anything goes wrong while obtaining references, we assume the worst and fail-over … If fault was transient, we’ll be back to primary upon next request …

„

But herein lies the bottleneck

Performing JNDI lookup and creating remote object for the same replica(s) every transaction … Big spike in fail-over, due to two lookups (with the first timing out) …

14 Team2 Final Presentation

S04-17654-A Analysis of Software Artifacts

Fail-Over Measurements (1) RTT(1 Client)

Milisecond

8000 6000 4000 2000 0 1

79

157 235 313 391 469 547 625 703 781 859 937 1015 1093 1171 1249 1327 1405 1483 Operation Number (one run through use case)

RTT( 20 Clients)

Milisecond

100000 80000 60000 40000 20000 0 1

316 631 946 1261 1576 1891 2206 2521 2836 3151 3466 3781 4096 4411 4726 5041 5356 5671 5986 Operation Number (one run through use case)

15

Team2 Final Presentation

S04-17654-A Analysis of Software Artifacts

Fail-Over Measurements (2) Fault Free Case (1 Client) JNDI Lookup Time Create Server 9% Home 12% View User List 79%

Faulty Case (1 Client)

View User List 19%

Create Server Home 38%

JNDI Lookup Time 43%

16 Team2 Final Presentation

S04-17654-A Analysis of Software Artifacts

Fail-Over Measurements (3) Fault Free Case (20 Client) JNDI Lookup Time, 19% View User List, 56%

Create Server Home, 25%

Faulty Case (20 Client)

View User List, 28%

Create Server Home, 27%

JNDI Lookup Time, 45%

17 Team2 Final Presentation

Real Time + FT + Baseline March 16 – April 5

S04-17654-A Analysis of Software Artifacts

RT-FT-Baseline Architecture (1) „ „

„

Upper-Bound the fail-over Target JNDI bottleneck by simply checking reference status instead of doing lookup … Instead of ‘lookup1-exception-lookup2’, we want ‘check-failover’ Separate JNDI lookups into a background thread … Runs at the beginning of execution, then sleeps until needed (i.e. when we catch an exception from the primary server).

19

Team2 Final Presentation

S04-17654-A Analysis of Software Artifacts

RT-FT-Baseline Architecture (2) Fault-Free Case Æ thread runs once and never again „ Faulty-Case Æ thread runs in the background, caching live references „

… Main

execution simply checks if the primary reference is valid … If it is not live, move on to secondary object and signal the thread to update the primary 20 Team2 Final Presentation

S04-17654-A Analysis of Software Artifacts

RT-FT-Baseline Architecture (3) „

Other Possibilities to bound fail-over … Client-Side

timeouts to reduce ‘failed’ lookup

times … Would bound fail-over to a constant factor of the timeout value + second lookup … However, after implementing the background thread to cache server references, adding timeout functionality does not improve failover times in the cases we consider (at least one ‘live’ server) … Did not implement based on these observations

21

Team2 Final Presentation

S04-17654-A Analysis of Software Artifacts

‘Real-Time’ Fail-Over Measurements Milisecond

RTT(1 Client) 7000 6000 5000 4000 3000 2000 1000 0 1

90

179 268

357 446 535

624 713

802 891 980 1069 1158 1247 1336 1425

Run Number

Upper Bound ~ 5900 ms

RTT(Caching / 1 Client)

Milisecond

8000 6000 4000 2000 0 1

89

177 265 353 441 529 617

705 793 881 969 1057 1145 1233 1321 1409 1497 Run Number

Upper Bound ~ 1500 ms

22

Team2 Final Presentation

S04-17654-A Analysis of Software Artifacts

‘Real-Time’ Fail-Over Measurements

Milisecond

RTT( 20 Clients) 100000 80000 60000 40000 20000 0 1

320 639 958 1277 1596 1915 2234 2553 2872 3191 3510 3829 4148 4467 4786 5105 5424 5743

Upper Bound ~ 78000 ms

Run Number

RTT(Caching / 20 Clients)

Milisecond

100000 80000 60000 40000 20000 0 1

98

195

292

389

486

583

680

777

874

Run Number

971 1068 1165 1262 1359 1456

Upper Bound ~ 6000 ms 23 Team2 Final Presentation

High Performance+ RT+FT+Baseline April 5 – April 13

S04-17654-A Analysis of Software Artifacts

High Performance Strategy „

“Functionality-Based” Load Balancing … Motivation Webservers „ Our Design „

… Benefits

Administrative actions do not suffer „ QOS can be assured by following some policy to split the functionality „ Decent level of Load Balancing is achieved with minimal effort „

25 Team2 Final Presentation

S04-17654-A Analysis of Software Artifacts

High Performance Architecture Client Tier

Middle Tier Server1

User Management Client applications

Backend

Purchase Order Management

MySql

Database

Server2

Inventory Management Sales Order Management Application Server (JBOSS) Naming Service (JNDI) KEY

JDBC Remote Method Invocation

Client applications Server application

Database

JNDI call

26

Team2 Final Presentation

S04-17654-A Analysis of Software Artifacts

Performance Measurements(1)

27 Team2 Final Presentation

S04-17654-A Analysis of Software Artifacts

Performance Measurements(2) Mean RTT vs. # Clients 350

300

Mean RTT

250

200

Normal Balanced 150

100

50

0 4

8

12

16

20

24

# Simultaneous Clients

28

32

36

40

28 Team2 Final Presentation

Conclusion

S04-17654-A Analysis of Software Artifacts

Insights From Measurements „

FT-Baseline … JNDI/Reference

lookups take large majority of RTT, especially in faulty case … Even in fault-free, doing the same lookup every time hurts RTT „

RT-FT-Baseline … Caching

of references nearly eliminates ‘spikes’ by reducing JNDI lookup time which is a bottleneck in Fault tolerant systems

„

High-Performance … Still

room for improvement of performance 30 Team2 Final Presentation

S04-17654-A Analysis of Software Artifacts

Accomplishments „

Nearly full ‘spike’ reduction with clientside reference caching (reduced RTT upper bound by 75% for 1 client, and 92% for 20 clients)

„

Fully-interactive client with automated test benches

„

Functionality-Based Load Balancing 31 Team2 Final Presentation

S04-17654-A Analysis of Software Artifacts

What we learned „

Working in distributed Teams … Thanks

to Assignment-1. CVS made life easy … Try Subversion

„

JBoss is great but ‘heavy’ … Startup

times, etc make testing difficult

„

Design decisions make project smoother

„

To conquer FT, RT, HP you need to fight 3 battles … Keeping

the server stateless makes the battle less complicated

32

Team2 Final Presentation

S04-17654-A Analysis of Software Artifacts

What more could we have done „

Optimizations on Server …

„

Bounded Failover …

„

Fine-tuning JBOSS may improve the performance Exception handling, TCP timeouts could be bounded

Hard-coded JNDI servers Separate the JNDI from JBOSS … Should probably be modularized in a config file or similar …

„

Load Balancing …

„

Functionality-based + Standard Load balancing Algorithms

Use Cases: Authentication … Searching … Messaging …

33 Team2 Final Presentation

S04-17654-A Analysis of Software Artifacts

Had we started over ! „

Administrative … Would

„

register for the course

Technical Would have … thought

twice about EJB and JBOSS … thought about Operation ID stuffing at the time of designing the system (Stateless vs Stateful server) 34 Team2 Final Presentation

Loading...

Sales Inventory Management System - CMU (ECE)

Team 2: Sales Inventory Management System Vamshi Ambati Myung-Joo Ko Ryan Frenz Cindy Jen S04-17654-A Analysis of Software Artifacts Team Members ...

561KB Sizes 5 Downloads 19 Views

Recommend Documents

Synopsis of Sales And Inventory Management System
Dec 13, 2016 - The main objective of the Sales And Inventory Management System is to manage the details of Purchasing, P

8086-1 - CMU-ECE
Bus'' in these descriptions is the direct multiplexed bus interface connection to the 8086 (without regard to additional

Inventory Management - Inventory Management System
But they find that Excel lacks the nuanced and comprehensive features they need to analyze data, spot trends in sales an

sales and inventory system documentation | Inventory | Business
INTRODUCTIONOverview of the Report The main objective of the study is to create an sales and inventory system for WMV En

Inventory Management System - Shopify
For example, Shopify's inventory management system lets you group products by category, type, season, sale and more. Aut

Order & Inventory Management System
Inventory Management System, part of a comprehensive, Web-based software application suite. The Order Management System

Inventory Management System - Dcag.com
Mar 18, 2012 - Inventory System. To provide Inventory System access to all necessary personnel (data entry, view, update

Android Project on Sales And Inventory Management System
Jun 17, 2016 - Download Android Project on Sales And Inventory Management System with source code, report, synopsis and

project report on sales and inventory management System - Scribd
This is to certify that Ms. ______has successfully completed her project work entitled “SALES AND INVENTORY MANAGEMENT

Sales and Inventory Management System - Free Student Projects
Apr 12, 2012 - Sales and Inventory Management System software is intended to collect, maintain and update all the inform