trijugnov

computerharpySoftware and s/w Development

Dec 2, 2013 (3 years and 7 months ago)

67 views

Jonathan Maron

Principal Product
Manager

Oracle Corporation

Tuning J2EE
Applications

Tier by Tier



Agenda


Background


Methodology


J2EE Optimizations


Performance Monitoring

Agenda


Background


Methodology


J2EE Optimizations


Performance Monitoring

Performance Issues Abound!

2003 Wily Benchmark Survey shows


60% of time Java applications fail to meet user
expectations


Only 42% of applications perform as planned during
deployment


57% of application performance spent in data access


2004 Forrester


66% of time developers find out about performance
problems from user calls!

J2EE Application Complexity


Enterprise

Information Systems


Client Side

Presentation

Desktop

Java

Application

Device

J2EE

Client

Browser

Pure

HTML

Java

Applet

J2EE

Platform


Web

Server


Server
-
Side

Presentation

JSP

Servlet

JSP

J2EE

Platform


EJB

Container


Server
-
Side

Business Logic

EJB

EJB

EJB

“Premature optimization is the root
of all evil”

-

Professor Sir Charles Anthony
Richard Hoare


There are two rules for when to
optimize:

1.
Don't do it.

2.
(For experts only) Don't do it
yet.”

-

Michael Jackson,
Principles of
Program Design


Test driven design can lead to
emergent optimization and code that
is readily optimizable. If programmers
develop test first, many of their upfront
concerns about performance can be
deferred.


-

Michael Feathers,
Emergent
Optimization in Test Driven Design

Agenda


Background


Methodology


J2EE Optimizations


Performance Monitoring

Methodical approach to
performance evaluation

Develop

Identify

Design

Test

Evaluate

Approach Tuning Issues
Logically and Iteratively

Java Virtual Machine

Application Server

Hardware and Operating System

Applications

Component

Database

Tuning and debugging are ongoing iterative

processes. There are no magic bullets.

Don’t Forget That There are
Tools to Help


Profilers


Debuggers


Code audits and metrics


Load testing tools


Vendor performance and configuration
guidelines

Agenda


Background


Methodology


J2EE Optimizations


Performance Monitoring

Tuning JDBC Performance:

Start with the Obvious


Use connection pooling


Connection objects are expensive


Tailor min and max connections to your
application


Avoid cycling physical database connections


Look for database connections timing out


Tune statement caching


Cache distinct SQL statements

No Connection Pooling

RacingFacade

J2EE Container



create



teamOrders



. . .

Make connection,

do Query

Return result

and disconnect

(unless application itself does

connection pooling)

With Connection Pooling

RacingFacade

J2EE Container



create



teamOrders



. . .

Application uses

available connections

Connection Pooling

From the Container

Tune Your SQL!


Easier said than done


What is the real SQL running in CMP EJB?


Look at the SQL on the wire


Tools like P6Spy, Oracle Enterprise Manager


Become good friends with your DBA


Tune using traditional techniques


Explain plan


Tools like SQLPlus and Oracle9
i

JDeveloper

D E M O N S T R A T I O N

JDBC
Performance

EJB
-

Locking
-
Mode and
Isolation


Pessimistic locking is generally slower


May be required for applications where data
collisions are likely


Increasing isolation decreases performance


Evaluate your data consistency requirements

Transactions and Performance


Entity beans load/store data at transaction
boundaries


Transactions settings affect how often database
is accessed


Poor performance can be caused by transaction
settings


Rules of thumb


Always use transactions for entity bean methods


Scope the unit of work from a session bean

Session Bean
-

Tx:None

Entity Bean
-

Tx:Required

TopicSessionFacade


createTopicSet


printTopicSet


deleteTopicSet

Topic


create


findBy


getTopicId


getTopicDesc


getTopicName


setTopicId


setTopicDesc


setTopicName

tx:None

tx:Required

System.out.println(“<Create Test>");

for(int i=0;i<3;i++)

{


TopicLocal topic =


topicHome.create(


new Integer(i),("topic " + i));


topic.setDesc("desc" + i);

}

System.out.println(“</Create Test>");

Resulting Transactional Activity

<Create Test>

TopicBean: ejbCreate id = 0

TopicBean: ejbStore id = 0

TopicBean: ejbLoad id = 0

TopicBean: ejbStore id = 0

TopicBean: ejbCreate id = 1

TopicBean: ejbStore id = 1

TopicBean: ejbLoad id = 1

TopicBean: ejbStore id = 1

TopicBean: ejbCreate id = 2

TopicBean: ejbStore id = 2

TopicBean: ejbLoad id = 2

TopicBean: ejbStore id = 2

</Create Test>

Tx create

Tx setDesc

Tx create

Tx setDesc

Tx create

Tx setDesc

Requires:

12 lifecycle

calls

Session Bean
-

Tx:Required

Entity Bean
-

Tx:Required

TopicSessionFacade


createTopicSet


printTopicSet


deleteTopicSet

Topic


create


findBy


getTopicId


getTopicDesc


getTopicName


setTopicId


setTopicDesc


setTopicName

tx:Required

tx:Required

System.out.println(“<Create Test>");

for(int i=0;i<3;i++)

{


TopicLocal topic =


topicHome.create(


new Integer(i),("topic " + i));


topic.setDesc("desc" + i);

}

System.out.println(“</Create Test>");

Resulting Transactional Activity

<Create Test>

TopicBean: ejbCreate id = 0

TopicBean: ejbCreate id = 1

TopicBean: ejbCreate id = 2

</Create Test

TopicBean: ejbStore id = 0

TopicBean: ejbStore id = 1

TopicBean: ejbStore id = 2

Tx : createTopic

Same code:

6 lifecycle

calls

Take Advantage of Your EJB
Container Configuration

Specifies how long to keep stateless sessions cached in the pool.

Stateless

Session

cache
-
timeout

Specifies whether the container updates only modified fields or all fields to
when ejbStore is invoked. Default true.

CMP

update
-
changedfield
-
only

Multiple users can execute the entity bean in parallel. The container does
not allow any updates to the bean's state.

CMP

read
-
only

Recommend setting to false to avoid the extra select before insert which checks if the
entity already exists before doing the insert. This will then detect a duplicate, if there is
one, during the insert.

CMP

do
-
select
-
beforeinsert





max
-
tx
-
retries

Specifies the maximum time to wait for any resource that the EJB container
needs before the container calls the EJB method (excluding DB).


Session &

Entity

call
-
timeout

Performance Characteristic Impacted

Type

Example

Parameter

Session &

Entity

Specifies the number of times to re
-
try a transaction that was rolled back due

to system level failures.

Tuning Servlet Performance:
Load on Startup


Increases application start
-
up time but
decreases first
-
request latency for servlets


How?


Add
<load
-
on
-
startup>
sub
-
element in


http
-
website.xml

to load the entire web
module on startup


Add
<load
-
on
-
startup>

sub
-
element to the
<servlet>

element in
web.xml
to load the
servlet on startup

Tuning JSP Performance:

Pre
-
Translation


Pre
-
compile JSPs into .class files ahead of
time


In Oracle Application Server, ojspc provides
this functionality


jsp, and .java


Batch compilation of war, jar, ear and zip files

% ojspc
-
dir /myapp/mybindir
-
srcdir /myapp/mysrcdir


MyPage.sqljsp MyPage2.jsp

% ojspc
-
deleteSource myapp.war

Use HTTPSession
Appropriately


Minimize the objects you store in HTTPSession


Takes up memory


Expensive serialization/deserialization if you use
persistence/replication


Use transient variables to reduce serialization
overhead


Reduce default session timeout by using
HttpSession.setMaxInactiveInterval()


Remove session objects when no longer in use


Use <%@ page session="false"%>

in JSP pages
where you do not need a session

Look for Bottlenecks with
Load Testing Tools


Mercury Loadrunner


Open source


Apache JMeter


Grinder


Altaworks Panorama




Scalability under varying load

Scalability
0
10
20
30
40
50
100
200
300
400
500
600
Clients
TPS
Vendor 1
Vendor 2
Manage Application Server JVMs
and Requests Per Application


Load balance across server instances


OC4J Process 2

JVM

OC4J Process 1

JVM

OC4J Instance

.

.

.

.

.

.

HTTP

Requests

.

.

.

D E M O N S T R A T I O N

Apache JMeter

Threads


more aren’t
necessarily better!


The optimum number of threads required will
probably vary based on application makeup
and load


Reduction of thread contention is key


Iterative process


Don’t get discouraged!

More threads


more
contention!

Transactions Per Second
0
50
100
150
200
250
300
2
4
8
16
32
64
Max Executor Pool Threads
Thread Group Lock Contention
0.00%
5.00%
10.00%
15.00%
20.00%
25.00%
30.00%
35.00%
40.00%
45.00%
50.00%
2
4
8
16
32
64
Max Executor Pool Threads
Thread Group CPU
0.00%
2.00%
4.00%
6.00%
8.00%
10.00%
12.00%
14.00%
16.00%
18.00%
2
4
8
16
32
64
Max Executor Pool Threads
Thread Group Waiting
0.00%
5.00%
10.00%
15.00%
20.00%
25.00%
30.00%
35.00%
40.00%
45.00%
50.00%
2
4
8
16
32
64
Max Executor Pool Threads
Objects


be economical!


Object creation is expensive


Especially exceptions


Assess whether unnecessary object creation
is occurring

JVM Tuning


A number of hotspot VM options are available
for tuning


-
Xms,
-
Xmx,
-
Xmn,
-
XX:SuvivorRatio,…


Some platform vendors provide additional
options


HP:
-
XX:+ForceMmapReserved


Some platforms are not properly tuned out of
the box for Java processing

Garbage Collection


Change the JVM Heap size


java

jar

Xms256m

Xmx256m oc4j.jar


Monitor collection cycles


verbose:gc


Profiling of heap


JDK 1.5 Jconsole


Intel Vtune


HPJtune


. . .


Agenda


Background


Methodology


J2EE Optimizations


Performance Monitoring

Performance Monitoring


Optimization doesn’t end with deployment


Monitoring tools key to continued application
responsiveness


Oracle Enterprise Manager


HP OpenView


. . .

Oracle Enterprise Manager

Final Thoughts


Performance tuning is an iterative process


An object pool is not always faster


Do not add threads haphazardly


Exceptions are expensive

Shameless Self Promotion