Ts2024 - Java2 Platform, Enterprise Edition (J2EE) Application Profiling - An Approach for Developers

8/22/2019 Ts2024 - Java2 Platform, Enterprise Edition (J2EE) Application Profiling - An Approach for Developers

1/53

java.sun.com/javaone/sf

| 2004 JavaOneSM Conference | Session TS-20241

Java 2 Platform,Enterprise Edition(J2EE) Application

Profiling: An Approachfor Developers

Lalitha Vishali

Principal Engineer

Pramati Technologieswww.pramati.com


2/53


Goal

What it takes to better J2EE application

performance numbers. Exploring theparadigm, the developers approach toProfiling and implementation details.


3/53


Do current tools in the market caterto specific details needed to profilea J2EE Application ??


4/53| 2004 JavaOneSM Conference | Session TS-20244

Agenda

The J2EEApplication Profiling Paradigm Motivation, existing tools, concerns

Approach to Profiling Framework: data collection, analysis, presentation layers

Dynamic proxies, bytecode instrumentation, JMX API Proof of Concept

Design overview

Bellwether parametersEJB, Web,Transaction, DB

Next Steps for the Framework Moving towards analysis, Thoughts for future



Agenda



Dynamic proxies, bytecode instrumentation, JMX API Proof of Concept

Design overview

Bellwether parametersEJB, Web, Transaction, DB




Optimization Challenges to Overcome

Identifying trouble spots made difficult byhuge number of components

Good grasp of J2EE application requiredfor configuring server

Application interaction with server is complex Configuration changes are typically chained

and may confound assessments

No tools available, task is specific to fewindividuals



More Optimization Challenges

Tuning often very specific to applicationdesign and load characteristics Thumb-rules may not work

Manual methods expensive, take time

You need J2EE/server vendor experts

Are there tools that meet those special optimizationdemands of J2EE applications?



Tools in the Market

OptimizeIT Substantially smaller set of features

JProbe Positioned as Java profilers

Memory profilers, allocation points and such Positioned as debuggers

Mercury LoadRunner, Astra LoadTest Load testers with simple timing collection modules

Wouldnt you like a server-agnostic J2EE profiler

that focuses on business methods and data pointsrelevant to tuning?

Why they dont meet J2EE application needs



J2EE App Profiling: The Beneficiaries

ISVs Performance regression benchmarking

Comparison with master result

Can be automated with their build systems

SIs Reduces costs, cuts project development time Reduces performance engineering effort

Eliminates need for experts in J2EE app Corporations

What are their concerns? Why do they need J2EEapplication profilers? What is the business case?



Concerns in the Production Scenario

Raw numbers without J2EE app relevancedont say much

Impressive graphs useless without intelligentanalysis in J2EE app context

Data pertinent to application tuning needed Just code level timings wont do

Spotting problem areas needing furtherperformance tuning

Macro-level tuning, not raw micro-level

method execution timings



Proposed Paradigm: suo moto

Gain the know-how to performance-engineer your J2EE application


12/53


Proposed Paradigm: Requirements

Understand your J2EE environment

Capture all entry points Obtain a drill-down view of all execution stacks

Timing analysis on specific execution points

No change in application vendorsinfrastructure


13/53


Agenda

The J2EE Application Profiling Paradigm Motivation, existing tools, concerns


Dynamic proxies,bytecode instrumentation,JMX API Proof of Concept

Design overview




14/53


Framework Architecture

DataGraphs

Reports

Config

Changes

Data

Application ServerInterceptor Layer

PersistenceMechanism

Rules Engine

(XML Based)

JMX Agent

BytecodeInstr.

DynamicProxy

Sniffers

Callbacks Processing /Analysis

DataCollection

Engine


15/53


Framework: Instrumentation Points

All spec-mandated callbacks

Servlet / JSP page service() methods Business methods in Bean Implementation

classes

Containers pre- and post-processing beforeand after the bean life cycle methods

Transaction begin and end calls Resource-related calls


16/53


Approach for Instrumentation

Bytecode Instrumentation and Reflection API To instrument pre- and post-processing calls

Dynamic Proxies Instrument the timing of life cycle methods

Determine occurrence of callbacks to life cyclemethods

Spec-mandated callbacks

Callbacks can be captured thru BytecodeInstrumentation or Dynamic Proxies

E.g., ejbStore(), ejbLoad() etc.


17/53


More Approaches for Instrumentation

Timing Diagnostic Framework Builds the drill-down execution paths

Times the key execution points

JMX implementationJSR-077 Data engine

Can obtain any statistics required for inference Vendor-neutral


18/53


Using Dynamic Proxy Stub Wrappers

Obtain a Context on Application ServersJNDI API tree

Lookup on stub of a given beans homeinterface

This stub is to be replaced by a proxy To create a proxy, we need

Context classloader, InvocationHandler,

the interface

InvocationHandlers invoke() handles requiredprocessing

Before and after the call to the stubs methods

H D i P St b


19/53


How Dynamic Proxy Stub

Wrappers Work

Stub(BeanHome1)

CustomizedProxy Generator

Dynamic Proxy of BeanHome1 Stub

Bind Dynamic Proxy with same JNDI name

Application Server

InvocationHandlers invoke()has the instrumented profiling

BeanHome1

JNDI Tree

Class

Loader

Class

Loader

Home

Interface

Home

Interface

InvocationHandler

Invocation

Handler

Obtain Contextic.lookup(BeanHome1)


20/53


Dynamic Proxies: Sample Code

public class DynamicProxyGenerator implementsRemote

{stub=context.lookup();homeIntf = Class.forName();proxy =

Proxy.generateProxy(ContextClassloader,homeIntf, MyInvocationHandler);context.bind(, proxy);

}

public class MyInvocationHandler implementsInvocationHandler {public Object invoke(Object proxy,

Method m1,Object[] args){return m1.invoke(delegate, args);}

}

Dynamic Proxy Generation for Home Stub


21/53


Bootstrap Classloader

Bytecode Instrumentation: Architecture

J2EE ApplicationApplication Server

ClassEnhanced

Extension Classloader

System Classloader

MYEJB

Class Preprocessor

Preprocessor

aware

Classloader

MYEJB

Classpath

Bytecode Instrumentation:


22/53



Configuration

Class Pre-processor:

Kicks-in just before Class loading Pre-processes Java classes

Uses a low-level API for bytecode modification

Class is enhanced without impacting class contract

Chained Pre-processors:

Set of pre-processors configured to handle a class Specific pre-processor enhances specific points

in a class

Class is modified by its pre-processor chain

Pre-processor Centric Configuration



23/53



Schematic API

// Schematic API of a preprocessorpublic interface ClassPreProcessor

{public abstract void initialize(Hashtable

hashtable);

public abstract byte[] preProcess(StringclassName, byte almostReadyBytecode[]);

}

Popular API : BCEL JakartaJavassist

Pre-processor Contract


24/53


Agenda

The J2EE Application Profiling Paradigm Motivation, existing tools, concerns


Dynamic proxies, bytecode instrumentation, JMX API

Proof of Concept Design overview

Bellwether parametersEJB, Web, Transaction, DB Next steps for the Framework

Moving towards analysis, Thoughts for future


25/53


Implementation POC

Timing details for critical J2EE applicationexecution points JSP/Servlet service() method execution time

EJB business method execution time

Prepared statement execution time

MDB onMessage() call

Drill-down details from entry points Show a hierarchical view of method execution

Diagnostics Framework: What is expected?


26/53


Diagnostics Framework Design

Link passes Taskpath in Querystring

HistogramData

Hits, Average,Cumulative counts

Tagcomponentfor

Histogram data

Tagcomponentfor

Timing data

TS

Tasknode3

TS

Tasknode2

TS

Tasknode1

Time Statistic. TimingMBean returns it for a TaskpathTSA list of all drilldown linksTaskpath


27/53


Instrumentation: Bellwether Parameters

Exploring streamwise the list of tuneableJ2EE application features EJB

Web

Transaction

Resource

The challenge is in making the set exhaustive

EJB Architecture Diagnostics


28/53



Instrumentation

Browser

Activation time

Store time

Memory

Database

Connection Pool

Load time

Instrumentation Points


29/53



Dynamic Proxy StubWrapper

Time spent on MDBsonMessage() call

Dynamic Proxy StubWrapper ejbCreate() andejbStore() calls

Time spent creating a bean instance

Dynamic Proxy StubWrapper

Time spent during load / store The ModalityThe Parameter

Instrumentation Points and the Modality



30/53



Instrumentation

Transaction Management

Persistence Management

Security Management

EJB, JNDI Contexts

Callback methods

Client

Request

EJB Container


EJB A hit t Di ti


31/53



Bytecode InstrumentationTime spent for locking a

bean instanceDynamic Proxy Stub WrapperTime spent during Activation/

Passivation

Bytecode InstrumentationTime spent for Pre-/Post-

Processing for any beanmethod call

Dynamic Proxy Stub WrapperBusiness MethodExecution Time

The ModalityThe Parameter


EJB A hit t Di ti


32/53



Bytecode

Instrumentation

Time spent acquiring and releasinga lock

BytecodeInstrumentation

Time spent waiting for a lock on PK


Total Bean Alive Time


Time spent waiting on a pool toget a bean





33/53



Screenshot

Hits Avg Time Cumulative Time

Drilldown viewMethod Execution Time



34/53


g

Screenshot

Timing Beans Life Cycle MethodCallbacks

Web Diagnostics Instr mentation


35/53


Web Diagnostics Instrumentation

Diagnostics FrameworkTracing the Execution PathFrom Entry points

Bytecode Instrumentation,JMX API

Service MethodExecution Time


Request

Web Container

Instrumentation

Pointfor Timing

Response Rate

1. Compiles the jsp

2. Executes _jspService()1. Compiles the jsp2. Executes _jspService()Browser


Web Diagnostics Screenshot


36/53


Web DiagnosticsScreenshot

Service Method Execution Times

Transaction Diagnostics


37/53


g

Instrumentation

Tx1

Tx2

Tx3

Request

Commit

Rollback

Instrumentation PointsApplication server



38/53



Bytecode InstrumentationTime spent committing aCMT/BMT

Bytecode InstrumentationTime spent completion ofCMT/BMT

Bytecode InstrumentationTime spent rolling back aCMT/BMT

Bytecode InstrumentationAverage Time spent on

transaction commit/rollback

Bytecode Instrumentationof Beans post-processing

Average Time spent ontransaction completion



Resource Diagnostics Instrumentation


39/53


Resource Diagnostics Instrumentation

Browser

Connection Pool

Database

Response

New Connection

Connection in

Transaction Cache

Application

ServerApplication

Server


Resource Diagnostics


40/53



JMX APIWait time to obtain connection

JMX APITime spent on prepared statement execution

JMX APIWait time to obtain connection from pool

JMX APIConnection Use Time

JMX APIWaiting Thread Time

TheModality

The ParameterInstrumentation Points and the Modality



41/53



JMX APIPrepared statements created afresh

JMX APIPrepared statements obtainedfrom cache

JMX APITime taken to obtain prepared

statement

JMX APIConnections created afresh





42/53


Screenshot

Hits Avg Time Cumulative Time

Resource timings in Method executioncontext



43/53


Screenshot

Datasource timing details

Agenda


44/53


Agenda


Approach to Profiling Framework: data collection,analysis,presentation layers Dynamic proxies, bytecode instrumentation, JMX API

Proof of Concept Design overview



Bean Concurrency


45/53


Bean Concurrency

Tabulate Frequency of Transaction participation (say, tp)

Frequency of Data store modifications (say, dm)

Average Number of threads waiting on Activebean instances (say, t)

Inference:

Compute the following ratio :dm

r = -------tp

If r is low, and t is high, suggest usage of OCC

Similarly can infer for suggestion of

Exclusive, Database or ReadOnly Concurrency

Bean Pool Sizes


46/53


Bean Pool Sizes

Entity Beans Min Bean Pool Size

Tabulate Number of Active Bean instances vs. Time

Max Bean Pool Size Compute Average Bean Holding Time for a client

Average number of client requests over Holding time= Bean Pool size

To avoid I/O due to Bean Passivation

Maximum number of client requests over Holding time

= Bean Pool size

Bean Load & Store Control Semantics


47/53


Bean Load & Store Control Semantics

Finders execute load Allows finders to load bean when finder is called

Group Loading Set of fields in the group are loaded with the EJB

Delay Database Insert Until Insert is called after ejbPostCreate() This avoids one database roundtrip

Lazy loading semantics BLOB/CLOB large varchar fields

Resource & Transaction Semantics


48/53


Connection Pool Usage Analysis This suggests appropriate pool sizes

Prepared statement execution times Suggests the one whose resultset needs caching

Transaction Usage Analysis

Tabulate frequency of transaction suspension Re-examine method causing it

Isolate finders that return single EJB Suggest usage of findByPK instead


49/53



Demo

| 2004 JavaOneSM Conference | Session 202449

Demo

J2EE Application Diagnostics

Summary


50/53


y

Try the suggested Approach to J2EEApplication Profiling

Allows easy Performance Engineering for developers

Proof of Concept design provides for good Benchmarktest numbers

Good configuration suggestions in EJB, Web, Transactionand DB parameters

For enhancements

Arrive at a Comprehensive set of tuning parameters

Build Analysis Reports suggesting requiredconfiguration changes

Better J2EE Application Performancenumbers now well within developerspurview

For More Information


51/53


Bytecode Instrumentation http://besee.sourceforge.net/besee-1-

x/overview/architecture.html

Jakarta's BCEL:http://jakarta.apache.org/bcel/manual.html

Dynamic Proxies to layer new functionality

http://java.sun.com/developer/TechTips/txtarchive/2000/May00_StuH.txt

Dynamic Proxy Classes

http://java.sun.com/j2se/1.3/docs/guide/reflection/proxy.html


52/53



Q&ADemo

| 2004 JavaOneSM Conference | Session 202452

Q&A

Lalitha Vishali


53/53



Java 2 Platform,

Enterprise Edition(J2EE) Application

Profiling: An Approachfor Developers

Lalitha Vishali

Principal Engineer

Pramati Technologies

www.pramati.com

Documents

Ts2024 - Java2 Platform, Enterprise Edition (J2EE) Application Profiling - An Approach for Developers