Architecting WAS based solutions for Reliability

1
Architecting WAS based solutions for Reliability
Performance

• Michael Locke, Candle

2
WebSphere Performance

• Performance and Availability problems . . .
• have moved to center stage
• no longer simply an issue with firms internal
  users
• affects customers, revenue, market share, brand
  equity
• but are typically . . .
• discovered late
• created early

• Life-cycle Best Practices are essential to . . .
• Uncovering latent problems that appear only under
  load conditions
• Ensuring applications meet end user requirements
  for response time and availability on day one
• Ensuring scalability to meet unexpected traffic
  peaks future growth

3
IBM Study factors inhibiting performance
scale
IBM Study Note based on 16 case studies of
WebSphere "performance critical situations."
(Nov 2002)
SOURCE Vanderham, Tim IBM Corporation,
presentation for session M21 at the WebSphere
Technical Exchange 2002, Las Vegas, NV, Nov-2002.
4
Aspects of Performance

• Throughput
• Response time
• First transaction
• Number of concurrent sessions
• Server Start time

5
Fundamentals of Performance

• Disk I/O is BAD for performance
• Network I/O is BAD for performance
• OS tasks are BAD for performance
• Spawning a new thread
• Memory allocation
• Garbage collection is BAD for Performance

6
Analysing a J2EEapplication

• PathWAI Performance Analyser

7
doPOST
8
getConnection x 47
9
doPOST
10
Resilience and Performance

• Efficient data storage
• HttpSesssions
• Stateful session beans
• Scalability

11
Efficient Data Storage
12
Session State

• Data needed to process a related group of requests

• Business data.
• Persistent life-time
• Often shared
• between applications or between users.

• State
• Needs to persist between requests.
• May be shared between servers

• Volatile data
• Local to one application, one user and one
  request.

13
Failures Survived
Lifetime
Data Type
C o s t
business data
Persistent
client, server, database
state
Session
cluster
server
client
Volatile
none
temporary data
14
Volume of Session state
Volume Size x Number of sessions
The more state data the higher the cost to store
it. Therefore - remove state data when it is no
longer needed - delete sessions once the business
process is complete - a time-out mechanism is
required - time-out must be set to allow for slow
or distracted users
15
Options for storing state
Application Server
Database
http
Browser

• Server
• Easy to code
• Less communications overhead
• Lost if server is lost

• Database
• Easy to share between servers
• Persistant
• More DB accesses

• Client
• Same life-time as client
• Passed in each request
• No server affinity problems

16
Options - In the Client

• Session data can be stored in the client and
  passed to the server in each request.
• Client browser
• Cookies
• URL re-writing
• Hidden fields (using an html form)
• Thick Client Memory

17
Options - In the Server

• HttpSession
• Most easy to implement
• Doesnt need an EJB container
• Session Beans
• More flexible - can be shared by non-servlet
  clients
• still need to cache the Session bean home in the
  servlet
• can direct and participate in transactions.

18
Options - In the Data base

• Persistant httpSessions
• Are normally cached in memory
• httpSessions can be configured to be written to
  the DB
• Will be written to the DB if volume of data is
  too large
• By the servlet
• By EJBs

19
Options
Client
Database
Server
Communications over-head
Most efficient if only one server
Extra DB accesses
Performance
Lost if client fails
Lost if server fails
Persistent
Resilience
Fully scalable
Session affinity or session replication
Limited by DB capacity
Scalability
Requires custom coding Limited amount of of
session data
Easy to implement
Easy to implement
Implementation
20
Choices

• The best option depends on requirements
• For scaling -
• For resilience - what failures should the session
  state survive.

21
Scalability
22
Designing for Scalability

• Problem
• - Entity beans are course-grained distributed
  persistent objects.
• Each client invocation on the entity bean is a
  remote network method
• call, which is expensive.

• Solution
• - Wrap the entity bean layer in a layer of
  session beans
• ( Session Façade pattern ).
• Clients should have access only to session
  beans not to entity beans.

23
Local EJB Interfaces

• Formerly all EJBs must be considered remote
• - Even if they were in the same JVM
• - Expensive in terms of time and memory
• Now we can optionally declare Local Interface
  for an EJB
• - EJBs within the same JVM can access each
  other directly
• - Pass-by-reference ( not pass-by-values )
  semantics
• Beans can be both local and remote
• - A local interface defines the local
  protocol
• - A remote interface defines the remote
  protocol

Warning limits the web site scalability
24
Replicated Application Servers
Application Server
E d g e S e r v e r
DB
Http server
Browser
Plug-in
Browser
Browser
Browser
Application Server
Http server
Plug-in
25
Session Affinity
Application Server
E d g e S e r v e r
Database
Browser
Application Server
Browser
26
Shared Session state
Application Server
E d g e S e r v e r
Database
Browser
Browser
Session state
Browser
Browser
Application Server
27
Summary

• Dont leave it too late to think about
• Reliability
• And
• Performance