JavaOne '99 Confidential

Performance and Scalabilityof EJB-based applications

Sriram SrinivasanPrincipal Engineer, BEA/WebLogic

JavaOne '99 Confidential

Scalability and performance

• Systems grow in many ways– Users, Data, Transaction Complexity

• Scaling a system:– Add hardware and change configuration

parameters to maintain or increase throughput– No change to application code or database

schema– System ensures that additional hardware is used

well

JavaOne '99 Confidential

What reduces scalability

• The same old reasons

• Contention for data

• Contention for processing units– CPUs, threads

• Contention for resources– Database connections– Memory, disk, I/O channels

JavaOne '99 Confidential

Plus some new twists

• Speed of deployment– Rapid time to market– Rapid scaling after announcing URL

• Distributed objects and components– Ease of use and seductive transparency

• Technological heterogeneity– Web servers, middleware, databases

• Performance issues forgotten until it is too late

JavaOne '99 Confidential

Responsibilities

• Everyone has certain responsibilities for increasing scalability– Bean designers

• End-to-end view required, not middleware or database-centric view.

• Know which improvements can be made after system is deployed.

– Server vendors– EJB spec writers at SUN

• Similar to ACID transaction properties – the "C" comes from the application

JavaOne '99 Confidential

Visualizing bottlenecks

Client App server DB Disk

Every node and link is a potential bottleneck

JavaOne '99 Confidential

Bottlenecks at nodes

• Appserver– Threads blocked on DB, on monitors– Unnecessary number of request-handling threads– Garbage collection

• Database server– Shared data– Unnecessarily strict isolation levels

• Profilers are useful but miss bigger patterns

JavaOne '99 Confidential

Bottlenecks at links

• Client to app server– Business methods, remote garbage collection, keep-

alive traffic

• Between app servers– Concurrency and caching protocols, distributed

transactions, object location

• App server to database

• Between DB servers– distributed transactions and lock management

• DB server to disk

JavaOne '99 Confidential

Overall recommendations

• Goal-directed design: Design UI first– Primary allegiance to user, so usability and

performance must be primary goals– Application designer first, bean designer later

• Plan for performance analysis– At design-time, know where to put hooks and how

to analyze the data

• Know thy application, know the hotspots

JavaOne '99 Confidential

Know thy application

• E-commerce apps– Lots of clients, high read/update ratio, low

contention, large working set

• Network management systems– Few operators, some hotspot network nodes

• Banks and ATMs– Lots of clients, low concurrency, high isolation

level, no working set

• Determine working set, concurrency and update requirements from use cases

JavaOne '99 Confidential

Myth: Stateless == scalable

• "Stateless == scalable" is meaningless– There's always state; only question is, where

does it live? – Stateless middle-tier ensures that middle-tier is

not the bottleneck– What do you do when DB becomes bottleneck?

• Statefulness is useful– Databases have caches, HTTP has cookies– In E-commerce apps, 90% activity is browsing– The lesser the dependence on cache coherence,

the closer cache can be towards client.

JavaOne '99 Confidential

Managing state

• Parameterized caches– Duration, amount, concurrency and replication

• Cache state separately for readers and writers, if possible

• Redesign if high amount of sharing– Queue requests from front-end– Do shared updates at end of transaction

• Entity beans only for shared data– Non-shared data become complex attributes

JavaOne '99 Confidential

Reducing traffic between client and app server

• UI talks to one bean (usually session)

• Make coarse-grained interfaces– Transfer data in bulk– Avoid IDL attributes– Only data should cross this interface, not object

references

• Avoid client-side transactions

• Use servlets instead of java applets

JavaOne '99 Confidential

Optimizations at app server

• Traffic between app server processes– Avoid distributing transactions– Partition requests and feed them to

corresponding processors

• Avoid long-running transactions

• Consider browsers separate from updaters

• Use JMS to enqueue requests

JavaOne '99 Confidential

Reducing traffic between app and DB servers

• Reducing amount of data transferred– Judicious use of caching at app server– Denormalization

• Reduce number of individual requests– Bulk accesses– Stored procedures

JavaOne '99 Confidential

Optimizing DB

• Data partitioning

• Putting database log on solid-state disks

• Custom SQL statements to give hints to optimizer

• Non-queryable attributes as blobs

• Using extended-relational database features

JavaOne '99 Confidential

How can app servers help ?

• State management– Provide configurable policies– Activation and deactivation policies

• Deactivate after timeout, after method, after transaction, never deactivate.

• Activate on demand– Concurrency (Optimistic, pessimistic)– Caching (with different isolation levels)

JavaOne '99 Confidential

Flexible caching strategies

• Depends on pattern of reads, updates and tolerance of cache incoherence

• Strategies:– Single location for a given primary key– Many instances (for one primary key) talking to

each other servers– Many instances talking only to DB

JavaOne '99 Confidential

How can app servers help? (contd.)

• Data partitioning– Factory-based routing– Data-dependent routing

• Connection management– Not have TCP connections from m clients to n servers

• Object and resource pooling

• Transparent failover and failback

• Monitoring hooks on requests, database drivers, caches

JavaOne '99 Confidential

What the EJB specification needs

• Bulk CRUD

• Relationships– And efficient traversals of relationships

• Explicit deactivation policies