J2EE Performance Tuning
by Sandeep Desai (http://www.thedesai.net/sandeep)
Java Tuning
- Use
StringBuffer instead of String
Java Memory Tuning
java ... -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC
-XX:NewSize=1200m -XX:SurvivorRatio=16
The reasoning for each setting is as follows:
-XX:+DisableExplicitGC - some libs call System.gc(). This is
usually a bad idea and could explain some of what we saw.
-XX:+UseConcMarkSweepGC - use the low pause collector
-XX:NewSize=1200m -XX:SurvivorRatio=16 - the black magic
part. Tuning these requires emprical observation of your GC log, either from
verbose gc or jstat ( a JDK 1.5 tool). In particular the 1200m new size is 1/4
of our heap size of 4800MB.
Oracle Database Tuning
- Tune
SQL queries when join tables put biggest filters right to left
- Create
Table Index
- Partition
Table
- Denormalize
tables
- Create
Oracle Materialized Views
J2EE optimization
Use
Clustering (see J2EE
Clustering article)
Servlet optimization
- Store
Attributes in Request objects instead of session so that they are garbage
collected sooner
- Avoid
using synchronized for methods
- Don’t
use Vector or Hashtable use Collection classes
- Using
too many custom tags can also slow down the application
- Peformance
and Load testing
- Measure
throughput (transactions per second)
- Average
transaction response time
- Hits
per second
- Steps
to improve performance
- take
a baseline (performance result before changes)
- Use
application knowledge or profilers to find bottlenecks
- make
application changes
- measure
performance
- Profilers
- Compuware
JProbe
- Rational
Quantify
- Inprise
OptmizeIt
- Performance
and Stress Testing tools
- Apache JMeter is a Desktop
tool (Java Swing) that can stress test a web server, it can also be use
for stress testing Java Objects, database etc
- Apache Flood is a HTTPD
load test
- The Grinder is a java based
open source HTTP stress testing tool
- Mercury
Interactive LoadRunner
- Radview
WebLoad
- Empirix
e-Test Suite
- Segue
Software, Inc SilkPerformer
- Microsft
WAS
Metrics
- Response time
- Throughput (Number of transaction executed
by system over a period of time)
- Resource Utilization (how heavily
particular system element is used)
- Service Demand = (Resource
Utilization/Throughput)
Response
time is end users experience of response, need to find out different response
time, e.g some user may have 1-second response and some may have 10 second.
Resource
utilization, measure utilization of contended resources
Throughput
and response times at odd for an interactive application
Metric
measurement add overhead
Measure
client response time using, browser scripting or synthetic transactions (more
popular). Make sure synthetic transactions are execute close to the client
No
standard in metrics between OS, database, Web Servers,
JVM
provides metrics using JMX
JMX
- object allocations/deallocations
- thread locks
- call stack
- method and line execution times
- JVMPI (JVM Profiling interface) for accessing
metrics
- JVMTI (JVM Tool interface)
- big overhead, not recommended for
production systems
J2EE Servers metrics
- Response time and utilization for
servlets, JSPs and EJBs
- Caching for EJBs, JDBC connections and
other service elements
- Utilization of services like JDBC, JMS,
JCA and JNDI
- Transactional information (# of rollbacks
and commits)
- Threading/queuing data (# of active
threads, # of waiting requests)
- JVM metrics (heap)
- General configuration information
- BEA Weblogic exposes metrics using JMX
- lacks response time for EJB methods
- IBM Websphere
- older version proprietary PMI interface
- new version 5.x PMI and JMX
- Oracle
- expose metrics using DMS servlet
- JBoss
- JMX
- exposes for both Tomcat and application
server
-
Other
approaches
- Protocol sniffers
- Use code instrumentation
- types
- granularity
- call counts
- time spent in method (Exclusive time)
- time spend in method and all method it
calls (cumulative time)
- exceptions thrown
- bytes transferred/serialized in RMI
- stack information