Optimizing J2EE Applications

Copyright 2001 Urbancode Software Development, Inc. All Rights Reserved.

Optimizing J2EE ApplicationsA Comparison of J2EE Design Idioms and their Performance

Presented by Maciej Zawadzki

[email protected]


Outline

• Introduction to EJBs

• EJB Performance Benchmark

• Beyond Performance: Code that is Simple and Easy to Maintain


Introduction to EJBs

• Introduction to EJBs– Three Tiered Architecture– Stateless Session EJBs– Stateful Session EJBs– Entity EJBs– Distributed Objects– Client View of EJBs

• EJB Performance Benchmark• Beyond Performance: Code that is Simple and Easy to

Maintain


Three Tiered Architectures

• Middle Tier houses system level services such as:– Remote access between clients and data sources– Session and transaction management– Security management– Resource access management (dbs. connection pooling)

Standard Three Tiered Architecture

Data TierMiddle TierClient Tier

MiddleTier

server

Web BrowserClient

Java ApplicationClient

Other IIOPClient

File SystemStorage

Legacy ApplicatData Source

DatabaseData Source


J2EE Three Tiered Architecture

• The EJB container and Web container make up the J2EE middle tier.

J2EE Three Tiered Architecture

Middle Tier

J2EE Server

EJB Container

EnterpriseBean

EnterpriseBean

EnterpriseBean

Web Container

JSP

Servlet

Client Tier

Web BrowserClient

Java ApplicationClient

Other IIOPClient

Data Tier

File SystemStorage

Legacy ApplicatData Source

DatabaseData Source


Stateless Session EJBs

• Not tied to any client• No data kept between method invocations• Do not survive beyond the lifetime of the J2EE server• Can access other resources available through the J2EE

server

Stateless Session Bean

EJB Container

MethodName()

EJB

RelationalDatabase

Other DataResource


Stateful Session EJBs

• Tied to a single client

• Can keep session data that survives between method invocations

• Do not survive beyond the lifetime of the J2EE server

• Can access other resources available through the J2EE server

Stateful Session Beans

EJB Container

MethodName()

EJBRelationalDatabase

Other DataResourceMethodName()

EJB


Entity EJBs

• Provide an object oriented representation of a row of data in a database

• Not tied to any client and can execute on behalf of multiple clients

• Built in protocol for data persistence via ejbLoad() and ejbStore() methods

Entity Beans

EJB Container

MethodName()

EJB

MethodName()

EJB


Distributed Objects

• Typical distributed object systems rely on Stub object on the client side to provide a proxy for the server side object.

• Method calls on the proxy are communicated to the server using a wire protocol.

• Arguments and return values are marshaled to and from the network data streams.

Typical Distributed Object Architecture

MethodName()

Stub

MethodName()

ClientAppNetwork

MethodName()

Skeleton

MethodName()

ServerApp

Wire Protocol suchas RMI or IIOP


Client View of EJBs

• Home interface provides remote access to a factory object

• Remote interface declares the business methods available on the EJB

Client View of EJBs

Client Application EJB Container

MethodName()

RemoteInterface

MethodName()

ClientApp

Network MethodName()

BeanClass

MethodName()

HomeInterface

MethodName()

RemoteInterface

MethodName()

HomeInterface


EJB Performance Benchmark

• Introduction to EJBs• EJB Performance Benchmark

– Five Design Idioms

– Four Tests (measuring relative performance of each idiom)

– Benchmark Results

– Explanation of Results

– Strategy for Optimized Performance

• Beyond Performance: Code that is Simple and Easy to Maintain


Benchmark Scenario

• Benchmark is a section of a J2EE application.

• Each inventory item consisted of: number, name, description, price, weight, weight unit of measure, manufacturer name.

• A database containing 1,000 records representing fictional inventory items was created.


Five Design Idioms

• Fine Grained Entity Bean (FGE) – often used by beginners to Enterprise Java Beans

• Coarse Grained Entity Bean (CGE) – the best performing Entity Bean idiom typically used in practice

• Optimized Entity Bean (OE) – the best performing contender that still uses Entity Beans

• Session over Entity Bean (SE) – typically advanced as a “best practice” in trade media

• Coarse Grained Session Beans (CGS) – the proposed best performer


Fine Grained Entity Bean Design Idiom

• The client calls accessor methods on an entity bean to read the value of every individual data member

Fine Grained Entity Bean Idiom

. . .

ItemStateDAO

findByPrimaryKey()findListOfLength()

FGItemHome<< EJBHome >>

Data Base

. . .

Client

getItemNumber()setItemNumber()getDescription()setDescription()getPrice()setPrice()getWeigth()setWeight()getWeightUOM()setWeightUOM()getManufacturerName()setManufacturerName()

FGItem<< EJBObject >>


FGItemBean<< Entity Bean >>


Coarse Grained Entity Bean Design Idiom

• The client uses an entity bean to retrieve a state object populated with database data

Coarse Grained Entity Bean Idiom

getState()

CGItem<< EJBObject >>

. . .

ItemStateDAO


CGItemHome<< EJBHome >>

Data BasegetState()

CGItemBean<< Entity Bean >>

. . .

Client


ItemState


Optimized Entity Bean Design Idiom

• The client uses an entity bean to retrieve a state object populated with database data. The entity bean does not update the data store unless the state has been changed.

Optimized Entity Bean Idiom

getState()

CGItem<< EJBObject >>

. . .

ItemStateDAO


CGItemHome<< EJBHome >>

Data BasegetState(). . .ejbStore()

CGItemBean<< Entity Bean >>

. . .

Client


ItemState

The ejbStore()method does

nothing unlessthe state has

been modified.


Session Over Entity Bean Design Idiom

• The client uses a session bean to retrieve a state object populated with database data, but the session bean populates the state object based on its conversation with a fine grained entity bean

Session over Entity Bean Idiom

. . .

ItemStateDAO


FGItemHome<< EJBHome >>

Data Base


FGItem<< EJBObject >>


FGItemBean<< Entity Bean >>

create()

ItemServicesHome<< EJBHome >>


ItemState

getItemStateForItemNumber()getItemStateListOfLength()

ItemServices<< EJBObject >>


ItemServicesBean<< SessionBean >>

. . .

Client


Coarse Grained Stateless Session Bean Design Idiom

• The client uses a stateless session bean to retrieve a state object populated with database data

Coarse Grained Session Bean Idiom

. . .

ItemStateDAO

create()


Data Base . . .

Client


ItemState






Four Tests

• Test 1 – designed to measure the relative performance when accessing a single instance of data

• Test 2 – designed to measure the relative performance when accessing small (up to 100 element) collections of data instances

• Test 3 – designed to measure the relative performance when accessing large (up to 1,000 element) collections of data instances

• Test 4 – a load test. Designed to measure relative performance when accessing a collection of 50 data instances by a varying number of clients concurrently.


Benchmark Setup

• App. Server – JBoss 2.0 with bundled Tomcat 3.2

• Database – Hypersonic (bundled with JBoss)

• Hardware – PIII 600Mhz (mobile) 392Mb RAM

• Operating System – Windows 2000


Results of Test 1(Single Instance Access)

3.62

6.02

9.6 10.02

31.64

0

5

10

15

20

25

30

35

Mill

ise

co

nd

s

Time 3.62 6.02 9.6 10.02 31.64

CGS OE CGE SE FGE


Results of Test 2

Restoring a Small Collection

0

500

1000

1500

2000

2500

3000

3500

Length of list

Mill

ise

co

nd

s

CGS

OE

CGE

SE

FGE

CGS 0 0 10 10 10 20 20 20 20 20

OE 90 50 90 91 120 200 340 511 451 550

CGE 70 140 181 240 301 431 501 571 741 892

SE 80 130 200 250 310 401 570 651 761 831

FGE 260 541 781 1,081 1,312 1,702 2,204 2,343 2,624 2,915

10 20 30 40 50 60 70 80 90 100


Results of Test 2 (cont.)(Regression Analysis)

• The CGS idiom is 121 times faster than the FGE idiom.

Idiom Slope Fit Factor

CGS 0.24 0.8335 1.00

OE 4.84 0.8234 20.27CGE 7.69 0.9452 32.18SE 7.86 0.9634 32.88

FGE 29.02 0.9911 121.43


Results of Test 3

Restoring a Large Collection

0

5000

10000

15000

20000

25000

30000

Length of list

Mil

lise

con

ds CGS

OE

CGE

SE

FGE

CGS 20 71 60 110 140 120 140 180 280 451

OE 230 461 681 891 1,142 1,392 1,602 1,802 2,033 2,264

CGE 601 1,191 1,773 2,324 2,934 3,475 4,066 4,637 5,187 5,828

SE 601 1,182 1,823 2,383 3,004 3,596 4,206 4,797 5,428 5,958

FGE 2,654 5,197 7,871 10,355 13,019 15,752 18,857 21,201 23,234 26,458

100 200 300 400 500 600 700 800 900 1,000


Results of Test 3 (cont.) (Regression Analysis)

• The CGS idiom is 86 times faster than the FGE idiom.

Idiom Slope Fit Factor

CGS 0.30 0.7441 1.00

OE 2.27 0.9996 7.50CGE 5.81 0.9998 19.19SE 6.00 0.9999 19.81

FGE 26.31 0.9991 86.94


Results of Test 4

Load Test (restoring a collection of 50 instances)

0

10000

20000

30000

40000

50000

60000

70000

80000

10 50 100 150 200 250 300

Numb. of Concurrent Clients

Mil

lise

con

ds

/ R

equ

est

CGS

OE


Results of Test 4 (cont.) (Regression Analysis)

• The CGE idiom scales 8.67 times better than the OE idiom.

Idiom Slope Fit FactorCGS 24.28 0.8610 1.00OE 210.48 0.9717 8.67


Explanation of Results

• Single instance access – EJB containers call ejbLoad() and ejbStore() methods automatically during transactions. If a method call requires a Transaction, then at least ejbStore() will be called before the Transaction associated with the method call completes, even if there has been no change to the state.

• Collection access – Entity beans know how to load (restore) only a single instance at a time. No optimizations for bulk access are possible when using Entity beans.


Strategy for Optimized Performance

• Practice Coarse Grained Access - State objects pattern (aka. Memento, Value Objects).

• Eliminate superfluous calls to ejbLoad() and ejbStore() – use Session Beans instead of Entity Beans

• Optimize bulk access – use a single conversation with the database when accessing multiple instances


Beyond Performance: Code that is Simple and Easy to Maintain

• Introduction to EJBs• EJB Performance Benchmark• Beyond Performance: Code that is Simple and Easy to

Maintain– Remaining problems– Domain Façade as a solution

• Introduction• UML diagram• Automatic Primary Key Dereferencing• Class = data + behavior• Layered and Columnar Architecture• Real World Implementation


Remaining Problems

• EJBs do not provide an elegant solution to automatic primary key dereferencing and object navigation.

• Coarse grained access patterns do not adhere to Object Oriented Programming principles:

• class = data + behavior


Introduction to the Domain Façade Idiom

• Builds on top of the Coarse Grained Session Bean idiom, thus maintains the performance advantage

• Adds the concepts of Domain Class and Domain Helper:– Domain Class – classes

whose instances wrap State object instances

– Domain Helper – utility classes that carry on conversations with EJBs

Domain Facade

Domain Class

StateDomain Helper

EJB Layer

Stateless SessionBean

Stateless SessionBean


Domain Façade Class Diagram

Domain Façade Idiom

. . .

ItemStateDAO

create()


Data Base

. . .

Client


ItemState





getItemNumber()getDescription()getPrice()setPrice()getWeigth()getWeightUOM()getManufacturerName()save()

Item<< DomainClass >>

getItemStateForItemNumber()getItemStateListOfLength()serviceState()

ItemHelper<< DomainHelper >>


Automatic Primary Key Dereferencing Example

• EJBs do not have object references to other EJBs, rather they hold the Primary Keys of referenced instances.

• Domain Classes provide object references.Domain Façade World

EJB World

Order EJB ItemEJB

Order DC Item DC

getItemID():Integer

getItem():Item


“Class = data + behavior” Example

• When using Domain Facades, the developer has complete control over which accessor and mutator methods should be available to the client.

• The developer can also add business methods that express behaviors.

Adding Behavior to the Data

Domain Class

State

Attribute

Attribute

Attribute

method


Layered and Columnar Architecture of Domain Facade

Layered and Columnar Architecture of Domain Facade

Data Base

Domain Façade Layer

EJB Layer

DAO Layer

Domain Columns

Legend

Domain Class

Domain Helper

EJB Home

EJB Remote

DAO


Business Logic Settles Close to the Client and Close to the Data StoreIt takes a lot of energy to keep business logic and data in the middle tier

Data TierMiddle TierPresentation Tier

Ene

rgy


A Detailed View of the Layers

• Each layer knows only about the layer behind it

• The loose coupling promotes:– code reuse– ease of maintenance– parallel development

MiddleTier

Enterprise Java Bean Layer

Web Layer

Data Tier

Client Tier

Session Enterprise Java Beans

Data Access Objects (DAO)

Data Store

Servlets JSPs

Browser

DomainClass DomainHelper

Presentation

Other Client


Alamo MPOWERENT Project

• Online rental management system• Available via extranet to insurance company partners• Fully integrated with legacy rental system• In production since August 2000• Over 8,000 business users• App. server on two clustered HP servers running

WebLogic 5.1• Average app. server CPU load is under 5%


Further Issues

• Treatment of dependent objects within the Domain Façade idiom

• Automatic state validation

• Non data intense domain classes that do not require the save() method


Summary

• EJB Performance– EJB Performance Benchmark– Lessons Learned / Strategy for Optimized

Performance– Turning Strategy into a Design

• Beyond Performance: Code that is Simple and Easy to Maintain– Remaining Problems – Absence of OOP– Domain Façade as a Solution


Thank you!Maciej Zawadzki

[email protected]


Benefits of Domain Façades

• Performance – built on top of best performing idiom

• Maintenance – layered architecture allows updates to any one layer to be isolated from all above layers. Columnar architecture makes updates to any one Domain column easy as all Domain related concepts (Domain Class and Helper, EJB, DAO) are isolated from any other Domain columns.

• Ease of Development– Automatic Primary Key dereferencing makes code more readable and

bug free.

– Ability to combine logic with data in adherence with OOP brings in all advantages of OOP.


EJB Broker Pattern


Persistence Services EJB Pattern


Domain Classes in Detail

• Private reference to a corresponding state object

• Constructor – accepts a state object– Called either for a restored instance, or – When a new instance is created

• Wrapping simple fields– Accessor calls are delegated to the state object– Mutator calls are delegated to the state object


Domain Classes in Detail (cont.)

• Wrapping reference fields– Accessor calls are intercepted. The PK of the referenced object is

obtained from the state object. The PK is then converted into a Domain Class reference by calling a lookup method on the associated Helper. The Domain Class reference may be cached for later usage.

– Mutator calls are intercepted. The PK of the Domain Class parameter is obtained and set on the state object. The Domain Class reference may be cached for later usage.

• The save() method– Calls the serviceState(…) method on the associated Helper with the state

object as a parameter. The method returns an updated state object which then becomes the new state.

Documents

Optimizing J2EE Applications