Massive Scale Deployments Tips Tricks Pitfalls Java One

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

Primary Purpose Discussion on Development & Design Techniques for Large & Massive Scale Web-Applications 1 | Java. One 2003 | Session #1870

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. Fort. Worth J 2 EE Sig. 1 | Java. One 2003 | Session #1870

Presentation Agenda Design Goals and Choices ● Deployment Strategies & Tricks ● Programming Tips & Pitfalls ● Future Choices ● Q&A ● 1 | Java. One 2003 | Session #1870

Design Goals and Choices Response Speed ● Scalability ● Reliability ● Failover ● Modularity ● Development Speed ● 1 | Java. One 2003 | Session #1870

Deployment Strategies & Tricks Packages and Multiple Jars ● Precompiling JSPs ● Ear files, EJBs, and Hot re-Deploys ● Clusters ● Refactoring Strategies ● 1 | Java. One 2003 | Session #1870

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 ● – – 1 Most appservers can recognize which EJB-Jars have been updated, and will only redeploy those For Developers, most App. Servers have unpacked directories that updated jars can be immediately redeployed to during a build. | Java. One 2003 | Session #1870

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 ● – 1 May need to merge generated JSP web. xml file with project's file for deployment | Java. One 2003 | Session #1870

EAR Files Most App. Servers 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 ● ● 1 many deployment scanners get confused with half -copied files, crashing the App. Server and forcing a restart | Java. One 2003 | Session #1870

Clusters Many Appservers now support this, with varying degrees of efficiency, reliability, and speed ● Usually a performance hit ● – – – 1 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 | Java. One 2003 | Session #1870

Clusters (continued) Transactions can be sped up by using READONLY Entity attributes (and Read-Mostly when available - for instance WL). ● 1 | Java. One 2003 | Session #1870

Refactoring Application Layer ● Development Group ● 1 | Java. One 2003 | Session #1870

Refactoring by Layer Presentation Layer ● Business Tier ● Sessions & Entities ● Data Access ● 1 | Java. One 2003 | Session #1870

Refactoring by 'Group' Individual ● Team Leader/Mentor ● Project Leader ● Group/Peer Review ● 1 | Java. One 2003 | Session #1870

Programming Tips & Pitfalls Identify Common Algorithms ●App. Servers are NOT created Equal ●Storing Objects in Sessions and Requests ●Optimizing & Profiling ● 1 | Java. One 2003 | Session #1870

Identify Common Algorithms (Refactor Continously) Identify and "Basify" Common Algorithms and Utility Functions ● – – 1 Watch for "Copy and Paste" of code by Developers Common/Base code into one or more Utility Jars | Java. One 2003 | Session #1870

App. Servers 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 ● 1 | Java. One 2003 | Session #1870

Storing Objects in Sessions & Requests When ● Why ● Consequences ● 1 | Java. One 2003 | Session #1870

Optimizing and Profiling Obvious stuff should be done early ● – – – Coarse grain EJB calls Caching EJB handles Don't cache object Handles Use String. Buffer 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 (String. Buffer Memory Leak) ● 1 Appeared in 1. 4. 1, Fixed in 1. 4. 1_04, 1. 4. 2 RC | Java. One 2003 | Session #1870

Optimizing & Profiling (continued) Keep Code Readable ● – – 1 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 | Java. One 2003 | Session #1870

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 ● 1 | Java. One 2003 | Session #1870

Future Choices App. Server Clustering vs OS Clustering ● Bandwidth vs Processing Power ● 1 | Java. One 2003 | Session #1870

Summary • Break Down EJBs into Groups, and put Groups in Jars • Pre. Compile JSPs • Profile everything 1 | Java. One 2003 | Session #1870

If You Only Remember One Thing… Profile 1 | Java. One 2003 | Session #1870

Q&A USEFUL RESOURCES ● ● Core J 2 EE Patterns - Best Practices and Design Strategies ● http: //kb. atlassian. com ● http: //www. javamug. org/mainpages/Java. html ● http: //www. scottcrawford. com | Java. One 2003 | Session #1870

| Java. One 2003 | Session #1870