Performance and Scalability of EJB-based applications Sriram Srinivasan

1. Performance and Scalabilityof EJB-based applications Sriram Srinivasan Principal Engineer, BEA/WebLogic JavaOne '99 Confidential

2. 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

3. 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

4. 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

5. 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

6. Visualizing bottlenecks Client App server DB Disk Every node and link is a potential bottleneck JavaOne '99 Confidential

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. What the EJB specification needs • Bulk CRUD • Relationships • And efficient traversals of relationships • Explicit deactivation policies JavaOne '99 Confidential