Massive Scale Deployments - PowerPoint PPT Presentation

About This Presentation
Title:

Massive Scale Deployments

Description:

Massive Scale Deployments Tips, Tricks, & Pitfalls Stephen Davidson Principal Associate Stephen Davidson & Associates, Inc Primary Purpose Speaker s Qualifications ... – PowerPoint PPT presentation

Number of Views:100
Avg rating:3.0/5.0
Slides: 27
Provided by: j2eeguysC
Category:

less

Transcript and Presenter's Notes

Title: Massive Scale Deployments


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

2
Primary Purpose
Discussion on Development Design Techniques for
Large Massive Scale Web-Applications
3
Speakers 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
QA
  • 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
(No Transcript)
Write a Comment
User Comments (0)
About PowerShow.com