Transcript No Slide Title

Performance and Scalability
of EJB-based applications
Sriram Srinivasan
Principal 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
Every node and link is a potential bottleneck
JavaOne '99 Confidential
Disk
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
JavaOne '99 Confidential