1. | JavaOne 2003 | Session #1870 Massive Scale Deployments Tips, Tricks, & Pitfalls Stephen Davidson Principal Associate Stephen Davidson & Associates, Inc

2. | JavaOne 2003 | Session #18701 Primary Purpose Discussion on Development & Design Techniques for Large & Massive Scale Web-Applications

3. | JavaOne 2003 | Session #18701 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. | JavaOne 2003 | Session #18701 Presentation Agenda ● Design Goals and Choices ● Deployment Strategies & Tricks ● Programming Tips & Pitfalls ● Future Choices ● Q & A

5. | JavaOne 2003 | Session #18701 Design Goals and Choices ● Response Speed ● Scalability ● Reliability ● Failover ● Modularity ● Development Speed

6. | JavaOne 2003 | Session #18701 Deployment Strategies & Tricks ● Packages and Multiple Jars ● Precompiling JSPs ● Ear files, EJBs, and Hot re-Deploys ● Clusters ● Refactoring Strategies

7. | JavaOne 2003 | Session #18701 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. | JavaOne 2003 | Session #18701 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. | JavaOne 2003 | Session #18701 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. | JavaOne 2003 | Session #18701 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. | JavaOne 2003 | Session #18701 Clusters (continued) ● Transactions can be sped up by using READ- ONLY Entity attributes (and Read-Mostly when available - for instance WL).

12. | JavaOne 2003 | Session #18701 Refactoring ● Application Layer ● Development Group

13. | JavaOne 2003 | Session #18701 Refactoring by Layer ● Presentation Layer ● Business Tier ● Sessions & Entities ● Data Access

14. | JavaOne 2003 | Session #18701 Refactoring by 'Group' ● Individual ● Team Leader/Mentor ● Project Leader ● Group/Peer Review

15. | JavaOne 2003 | Session #18701 Programming Tips & Pitfalls ● Identify Common Algorithms ● AppServers are NOT created Equal ● Storing Objects in Sessions and Requests ● Optimizing & Profiling

16. | JavaOne 2003 | Session #18701 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. | JavaOne 2003 | Session #18701 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. | JavaOne 2003 | Session #18701 Storing Objects in Sessions & Requests ● When ● Why ● Consequences

19. | JavaOne 2003 | Session #18701 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. | JavaOne 2003 | Session #18701 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. | JavaOne 2003 | Session #18701 Optimizing & Profiling When 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. | JavaOne 2003 | Session #18701 Future Choices ● AppServer Clustering vs OS Clustering ● Bandwidth vs Processing Power

23. | JavaOne 2003 | Session #18701 Summary Break Down EJBs into Groups, and put Groups in Jars PreCompile JSPs Profile everything

24. | JavaOne 2003 | Session #18701 If You Only Remember One Thing… Profile Profile Profile

25. | JavaOne 2003 | Session #1870 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

26. | JavaOne 2003 | Session #1870