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

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

| 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, million concurrent users The Web Domains developed have had Applications, with multiple "screens" per application Stephen Davidson is the Chair of the Dallas- FortWorth J2EE Sig.

| JavaOne 2003 | Session #18701 Presentation Agenda ● Design Goals and Choices ● Deployment Strategies & Tricks ● Programming Tips & Pitfalls ● Future Choices ● Q & A

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

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

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

| 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

| 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

| 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

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

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

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

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

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

| 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

| 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

| JavaOne 2003 | Session #18701 Storing Objects in Sessions & Requests ● When ● Why ● Consequences

| 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 # (StringBuffer Memory Leak) ● Appeared in 1.4.1, Fixed in 1.4.1_04, 1.4.2RC

| 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

| 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

| JavaOne 2003 | Session #18701 Future Choices ● AppServer Clustering vs OS Clustering ● Bandwidth vs Processing Power

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

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

| JavaOne 2003 | Session #1870 Q&A ● USEFUL RESOURCES ● Core J2EE Patterns - Best Practices and Design Strategies ● ● ●

| JavaOne 2003 | Session #1870