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
Top Related