JavaOne '99 Confidential 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 ClientApp serverDBDisk 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