massive scale deployments

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

Upload: jerod

Post on 09-Jan-2016

34 views

Category:

Documents


3 download

DESCRIPTION

Massive Scale Deployments. Stephen Davidson Principal Associate Stephen Davidson & Associates, Inc. Tips, Tricks, & Pitfalls. Primary Purpose. Discussion on Development & Design Techniques for Large & Massive Scale Web-Applications. Speaker’s Qualifications. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Massive Scale Deployments

| JavaOne 2003 | Session #1870

Massive Scale DeploymentsTips, Tricks, & Pitfalls

Stephen DavidsonPrincipal AssociateStephen Davidson & Associates, Inc

Page 2: Massive Scale Deployments

| JavaOne 2003 | Session #18701

Primary Purpose

Discussion on Development & Design Techniques for Large & Massive Scale Web-Applications

Page 3: Massive Scale Deployments

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

Page 4: Massive Scale Deployments

| JavaOne 2003 | Session #18701

Presentation Agenda

●Design Goals and Choices●Deployment Strategies & Tricks●Programming Tips & Pitfalls●Future Choices●Q & A

Page 5: Massive Scale Deployments

| JavaOne 2003 | Session #18701

Design Goals and Choices

●Response Speed●Scalability●Reliability ●Failover●Modularity●Development Speed

Page 6: Massive Scale Deployments

| JavaOne 2003 | Session #18701

Deployment Strategies & Tricks

●Packages and Multiple Jars●Precompiling JSPs●Ear files, EJBs, and Hot re-Deploys●Clusters●Refactoring Strategies

Page 7: Massive Scale Deployments

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

Page 8: Massive Scale Deployments

| 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

Page 9: Massive Scale Deployments

| 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

Page 10: Massive Scale Deployments

| 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

Page 11: Massive Scale Deployments

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

Page 12: Massive Scale Deployments

| JavaOne 2003 | Session #18701

Refactoring

●Application Layer●Development Group

Page 13: Massive Scale Deployments

| JavaOne 2003 | Session #18701

Refactoring by Layer

●Presentation Layer●Business Tier●Sessions & Entities●Data Access

Page 14: Massive Scale Deployments

| JavaOne 2003 | Session #18701

Refactoring by 'Group'

●Individual●Team Leader/Mentor●Project Leader●Group/Peer Review

Page 15: Massive Scale Deployments

| JavaOne 2003 | Session #18701

Programming Tips & Pitfalls

●Identify Common Algorithms●AppServers are NOT created Equal●Storing Objects in Sessions and Requests●Optimizing & Profiling

Page 16: Massive Scale Deployments

| 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

Page 17: Massive Scale Deployments

| 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

Page 18: Massive Scale Deployments

| JavaOne 2003 | Session #18701

Storing Objects in Sessions & Requests

●When●Why●Consequences

Page 19: Massive Scale Deployments

| 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

Page 20: Massive Scale Deployments

| 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

Page 21: Massive Scale Deployments

| JavaOne 2003 | Session #18701

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

Page 22: Massive Scale Deployments

| JavaOne 2003 | Session #18701

Future Choices

●AppServer Clustering vs OS Clustering●Bandwidth vs Processing Power

Page 23: Massive Scale Deployments

| JavaOne 2003 | Session #18701

Summary

• Break Down EJBs into Groups, and put Groups in Jars

• PreCompile JSPs

• Profile everything

Page 24: Massive Scale Deployments

| JavaOne 2003 | Session #18701

If You Only Remember One Thing…

Profile Profile Profile

Page 25: Massive Scale Deployments

| 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

Page 26: Massive Scale Deployments

| JavaOne 2003 | Session #1870