25 May Code 3C3 Peeling the Layers of the 'Performance Onion John Murphy, Andrew Lee and Liam Murphy

Transcription

1 UK CMG Presentation 25 May Code 3C3 Peeling the Layers of the 'Performance Onion John Murphy, Andrew Lee and Liam Murphy

2 Is Performance a Problem? Not using appropriate performance tools will cause 20% of enterprise mission-critical applications to experience severe performance problems (Gartner) 25% increase in effort/time for troubleshooting application and network problems (Gartner) 67% of IT managers expect to increase budgets for performance management tools (Newport Group Research)?% of enterprise systems go live with no load testing

3 Traditional Approach Performance Test on pre-production environment Decide Design Develop Deploy Experience Shows Time is Critical Mistakes are costly

4 Problems with Traditional Methods Traditional Monitoring/Testing Tools: Need Production like environments Only available at end of project Costly to construct & maintain Find Problems one at a time Multiple Fix-Test-Fix cycles Testing Takes Time and Money

5 Performance Drivers Frustration of trying to build enterprise applications on time under budget to meet user performance expectations Key customer needs include easier data collection (70% of performance project) presenting knowledge not data empowering more people to do the job potential to save enterprises significant time & money through enhanced performance tools

6 The Performance Onion Synchronous Messaging Too Many Method Calls Single Threaded Code Inefficient Code DB Indexes

7 Performance Prediction What is performance prediction? Finds further bottlenecks in the system Why use performance prediction? Faster time to market Value of performance prediction? Reduces multiple fix-test-fix cycles

8 The 4 Key Predictions Looking beyond the current performance problem Multiple load testing cycles Where do I focus my efforts to optimize the system Blindly fixing code too much Predicts performance for different hardware How does this scale to bigger hardware Expands the performance test envelope Guessing the places to load test the system

9 Peeling the Onion Helps find all the Performance Problems at once Synchronous Messaging Too Many Method Calls Single Threaded Code Inefficient Code DB Indexes

10 Focusing the code improvement cycles Explores all possible ways to get required response times

11 Bigger Hardware Content Providers Firewall LAN LAN LAN Web Servers Application Servers Legacy System Find Performance Problems on less or different hardware DB Servers DB Servers

12 Virtual Performance Test Lab Performance testing takes time Volume Now Tests full that coverage can be run means few tests are run, leaving problems undetected Scenarios

13 Overview of Onion Peeling Where are the Performance Bugs? Capture Edit Predict

14 Capture (Profile) Use a Profiler or Apps to gather the Performance Data Performance Data

15 Edit Reams of Performance Data Define Test Cases

16 Prediction Results

17 Case Study of a middleware system Application Server Internet Firewall Web- Server Response Time against Load Application 2 Data- Base User PC Application 1 Application Load

18 Component Technologies CORBA (Common Object Request Broker Architecture) Open standard created by OMG.NET framework Developed by Microsoft EJB (Enterprise JavaBeans) Developed by SUN J2EE technology de facto standard 65-75% enterprises (Gig 2002)

19 Components A component is a lego tm like piece of code Allow developers to concentrate on business logic Decouple the logic from architecture Distributed Components offer: Security Robustness Persistence Transactional capability Scalability

20 Components Reservation Payment Payment ORB ORB

21 Distributed Objects Client Network Application Server 1. Invoke Method 2. Communicate Method Invocation Stub 5. Return Result 4. Communicate Result Skeleton Server Object 3. Invoke Method

22 J2EE (Java 2 Enterprise Edition)

23 EJB (Enterprise JavaBeans) SUN Microsystems definition of Enterprise JavaBeans is: The Enterprise JavaBeans architecture is a component architecture for development & deployment of component-based distributed business applications. Applications written using the EJB architecture are scalable, transactional, and multi-user secure. The application may be written once, and deployed on any server platform that supports the Enterprise JavaBeans specification.

24 Know Your Beans! Entity Beans Hold persistent data structures used by application Bean represents a logical record in DB Session Beans Workflow or task oriented Can be stateless or stateful (conversational state) Message Beans Asynchronous messaging Doesn t have remote/local/home interfaces Loosens coupling between sender and receiver

25 Design Decisions What s the best design?

26 EJB Design Decisions Communication Overhead When to use local vs. remote interface calls Entity Beans Does the data model map to entity beans? Stateless vs. Stateful beans Container Managed Persistence vs. Bean Managed Persistence

27 Other Performance Problems: What leading experts say The performance challenges typically revolve around excessive or inefficient accesses to backend systems such as databases and mainframe systems. Poor design does not allow optimization Excessive method calls Not designing in an architectural context No consideration for concurrent users Tuning the number of JVMs serving the clients and tuning the number of threads per JVM

28 UML Model

29 Data Collection

30 Conclusions Performance is a growing problem for enterprise systems Using the Onion model will help to assure system performance