Massive Scale Deployments

1. Massive Scale Deployments Stephen Davidson Principal AssociateStephen Davidson & Associates, Inc Tips, Tricks, & Pitfalls

2. Primary Purpose Discussion on Development & Design Techniques for Large & Massive Scale Web-Applications

3. Speaker’s Qualifications • Stephen Davidson has worked as a Developer and Technical Lead for three years on Massive Scale Applications • The Web Domains Stephen has worked on have been designed to support 150,000 - 2 million concurrent users • The Web Domains developed have had 12 - 15 Applications, with multiple "screens" per application • Stephen Davidson is the Chair of the Dallas-FortWorth J2EE Sig.

4. Presentation Agenda • Design Goals and Choices • Deployment Strategies & Tricks • Programming Tips & Pitfalls • Future Choices • Q & A

5. Design Goals and Choices • Response Speed • Scalability • Reliability • Failover • Modularity • Development Speed

6. Deployment Strategies & Tricks • Packages and Multiple Jars • Precompiling JSPs • Ear files, EJBs, and Hot re-Deploys • Clusters • Refactoring Strategies

7. Packages and Multiple Jars • One Application should not do all. Look for logical breaks. • Breaking code down by packages per Application makes for; • Easier Testing/Debugging • Faster Redeployments • 1 or 2 Packages per Jar makes for faster redeployments • Most appservers can recognize which EJB-Jars have been updated, and will only redeploy those • For Developers, most AppServers have unpacked directories that updated jars can be immediately redeployed to during a build.

8. Precompiling JSPs • Most Appservers supply a JSPC tool (jsp compiler), including Weblogic & JBoss • Advantages • Find compile bugs during development/build • Immediate deployment of JSPs, user does not need to wait for JSP to compile • Disadvantage • May need to merge generated JSP web.xml file with project's file for deployment

9. EAR Files • Most AppServers unpack before deploying contents • Many Appservers will check to see which jars (especially ejb jars) have been changed before redeploying jar (ex. Orion, JBoss) • Deploying Jars in an Ear helps EJB Container keep classes synchronized across jars. • If large file being copied over network, copy to another extension, then rename • many deployment scanners get confused with half-copied files, crashing the AppServer and forcing a restart

10. Clusters • Many Appservers now support this, with varying degrees of efficiency, reliability, and speed • Usually a performance hit • Session Data has to be copied across cluster • Other nodes have to be monitored (by Appserver) • Transactions can be distributed over other machines in cluster

11. Clusters (continued) • Transactions can be sped up by using READ-ONLY Entity attributes (and Read-Mostly when available - for instance WL).

12. Refactoring • Application Layer • Development Group

13. Refactoring by Layer • Presentation Layer • Business Tier • Sessions & Entities • Data Access

14. Refactoring by 'Group' • Individual • Team Leader/Mentor • Project Leader • Group/Peer Review

15. Programming Tips & Pitfalls • Identify Common Algorithms • AppServers are NOT created Equal • Storing Objects in Sessions and Requests • Optimizing & Profiling

16. Identify Common Algorithms (Refactor Continously) • Identify and "Basify" Common Algorithms and Utility Functions • Watch for "Copy and Paste" of code by Developers • Common/Base code into one or more Utility Jars

17. AppServers are NOT created equal • Weblogic vs JBoss • Deploy Speed • Start Speed • Support • Functions and Reliability • Hot Redeploy - test with YOUR Application! • Certification Issues • For more comprehensive studies, c/o http://www.scottcrawford.com

18. Storing Objects in Sessions & Requests • When • Why • Consequences

19. Optimizing and Profiling • Obvious stuff should be done early • Coarse grain EJB calls • Caching EJB handles • Don't cache object Handles • Use StringBuffer for concats, instead of Strings • Write Byte/Char arrays to sockets, instead of Strings - its much faster • If JDK 1.4+, lookout for Bug #4724129 (StringBuffer Memory Leak) • Appeared in 1.4.1, Fixed in 1.4.1_04, 1.4.2RC

20. Optimizing & Profiling (continued) • Keep Code Readable • Don't try to optimize code during initial development • Why save a few milleseconds when their may be places with delays of several seconds? • Keeping code readable gets code done faster with fewer errors • Easier to Debug

21. Optimizing & ProfilingWhen to Profile? • Depends on Experience of Developer • If 'new', then generally more frequently, such as when a major object or method is completed • When more experienced, less frequently, but still at major milestones • Just BEFORE Integration with other components • Make sure that everything is running at reasonable efficiency • Just AFTER Integration with other components

22. Future Choices • AppServer Clustering vs OS Clustering • Bandwidth vs Processing Power

23. Summary • Break Down EJBs into Groups, and put Groups in Jars • PreCompile JSPs • Profile everything

24. If You Only Remember One Thing… Profile Profile Profile

25. Q&A USEFUL RESOURCES Core J2EE Patterns - Best Practices and Design Strategies http://kb.atlassian.com http://www.javamug.org/mainpages/Java.html http://www.scottcrawford.com