Download tomcat_performance_tuning_20071015

Performance Tuning
Apache Tomcat
Steve Heckler, President
Accelebrate
http://www.accelebrate.com
[email protected]
What We’ll Cover
• Removing unneeded applications
• Tuning and monitoring the JVM
– This section “borrows” some from Sun’s official documentation
• Tuning and monitoring connectors
• Compiling native connectors
• Tuning and monitoring database connection pools
• Turning off JSP development mode
• Reducing logging
• Precompiling JSPs and caching output
2
Tomcat Version in Use
• We’ll use Tomcat 6, but the majority of strategies shown
are applicable to earlier versions
3
Tomcat Versions (see http://tomcat.apache.org for details)
General
Version
Latest
Version
JDK
Servlet API
JSP API
3.3.x
3.3.2
1.2+
2.2
1.1
4.1.x
4.1.36
1.2+
2.3
1.2
5.0.x
5.0.28
1.4+
(1.3)
2.4
2.0
5.5.x
5.5.25
1.5+
(1.4)
2.4
2.0
6.0.x
6.0.14
1.5+
2.5
2.1
4
Word of Advice #1:
Use a Recent Java SE version
• Java 1.5 sizes heap generations much more
efficiently than 1.4 and earlier
• Java 1.6 has an option to perform garbage
collections in parallel (more about this later)
5
Remove Unneeded Applications
• At your discretion, you can remove every
installed application that ships “out of the
box” in Tomcat
• This will save you startup time, as well as
memory used by preloaded servlets
• ROOT should definitely be replaced
• Only keep manager (and in 5.5 and later,
host-manager) if you need them
6
Tomcat Monitoring
• Tomcat is difficult to monitor prior to Java
1.5 and later builds of Tomcat 4.1.x
• Java 1.5 and later support monitoring the
JVM using JConsole and the jstat command
line tool (both included with the JDK)
• Tomcat 5.0 and later have especially good
JMX MBeans support
7
What are JMX and MBeans
• JMX: Java Management Extensions, a standard way of
managing Java applications
• MBeans: Management beans. An application can provide
management beans that enable you to interact with and
configure the applications. MBeans have:
– Attributes that you can get or set
– Operations that you can invoke
• MBeans can be interacted with programmatically or via
JConsole
8
Enabling JMX monitoring
(via setenv.sh)
#!/bin/sh
if [ "$1" = "start" ] ; then
CATALINA_OPTS="$CATALINA_OPTS \
-Dcom.sun.management.jmxremote"
# -Dcom.sun.management.jmxremote.port=9086 \
# -Dcom.sun.management.jmxremote.ssl=false \
# -Dcom.sun.management.jmxremote.authenticate=false"
echo $0: CATALINA_OPTS = "$CATALINA_OPTS"
fi
9
Enabling JMX Monitoring
(Windows)
• In a production environment, you can set
these in CATALINA_OPTS by editing the
service.bat before registering the service
• Alternatively, edit the registry keys directly
after the service is registered
10
JMX Monitoring: Key Decisions
• Only specify a port if you want to allow
remote access (potentially a security hole)
• Consider configuring authentication and/or
SSL if you do open a port
– http://java.sun.com/j2se/1.5.0/docs/guide/mana
gement/agent.html has details on this
11
Once JMX is enabled
• You can run jconsole from the command
line of any computer with JDK 1.5 or later
installed
• Accessing your JVM remotely will require
that a port be opened
• jstat can be run locally to monitor your
JVM (dumps output to STDOUT)
12
Introduction to Java
Garbage Collection
• Java memory utilization and garbage
collection are two of the most critical issues
in Tomcat performance tuning.
• Garbage collection is the process whereby
memory is reclaimed from the application
• Java tends to shield developers from control
of garbage collection, but not from the
consequences
13
Introduction to Java
Garbage Collection
• In Java, objects become eligible for garbage
collection when they no longer have any
references pointing to them
• The story of how this occurs is rather
complicated…
14
GC Scalability
(graphic shown at http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html)
15
GC Scalability
• Demonstrates that an application that
spends 10% of its time in garbage collection
can lose 75% of its throughput when scaled
out to 32 processors
16
Heap versus Non-Heap Memory
• JVM manages 2 kinds of memory: heap and
non-heap:
– Heap memory is the runtime data area from
which the JVM allocates memory for all class
instances and arrays.
– The heap may be of a fixed or variable size.
– The garbage collector is an automatic memory
management system that reclaims heap memory
for objects.
17
Heap versus Non-Heap Memory
– Non-heap memory includes a method area
shared among all threads and memory required
for the internal processing or optimization for
the JVM.
– It stores per-class structures such as a runtime
constant pool, field and method data, and the
code for methods and constructors.
18
Heap versus Non-Heap Memory
– A JVM implementation may require memory
for internal processing or optimization which
also belongs to non-heap memory.
– For example, the JIT compiler requires memory
for storing the native machine code translated
from the JVM code for high performance.
19
Garbage Collection
• Garbage collection (GC) is how the JVM frees memory
occupied by objects that are no longer referenced.
• It is common to think of objects that have active references
as being "alive" and un-referenced (or unreachable) objects
as "dead.“
• Garbage collection is the process of releasing memory
used by the dead objects. The algorithms and parameters
used by GC can have dramatic effects on performance
20
Generational Garbage Collection
• In practice, most programs create:
– many objects that have short lives (for example,
iterators and local variables).
– some objects that have very long lifetimes (for
example, high level persistent objects)
21
Generational Garbage Collection
• GC divides memory into several
generations, and assigns each a memory
pool.
• When a generation uses up its allotted
memory, the VM performs a partial garbage
collection (also called a minor collection)
on that memory pool to reclaim memory
used by dead objects.
• This partial GC is usually much faster than
a full GC.
22
Generational Garbage Collection
• Generations:
– young generation (“the nursery”)
• eden space
– Most objects initially assigned here (and die here)
• two survivor spaces
– Objects that survive a minor GC in eden space are moved here
– old generation
• tenured space
– Objects that survive long enough in the survivor spaces
– When tenured space fills up, full GC occurs (often slow and involves all
live objects)
– permanent generation
• holds all the reflective data of the virtual machine itself, such as class
and method objects
23
Generational Garbage Collection
• If the garbage collector has become a bottleneck, you may
be able to improve performance by customizing the
generation sizes.
• http://java.sun.com/docs/hotspot/gc/index.html details how
to customize these sizes.
– Java 6 version at
http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.ht
ml
• Customizing the sizes is less necessary in Java 1.5 and
later
24
Tuning the Total Heap
• Total available memory is the most important knob
affecting GC performance
• By default, the JVM grows or shrinks the heap at each
collection to try to keep the proportion of free space to
living objects at each collection within a specific range
• This target range is set as a percentage by the parameters XX:MinHeapFreeRatio=<minimum> and XX:MaxHeapFreeRatio=<maximum>, and the total size
is bounded below by -Xms and above by -Xmx
25
Tuning the Total Heap
• Some notes:
– Unless you have problems with pauses, try granting as
much memory as possible to the JVM. The default size
(64MB on a 32-bit OS) is often too small.
– Setting -Xms and -Xmx to the same value increases
predictability by removing the most important sizing
decision from the JVM.
– Be sure to increase heap size as you add cores or
processors
– 32-bit OSes cap the heap size at between 1.5 and 2.5GB
26
Tuning and Monitoring
Connectors
• Tomcat supports connectors for http, https, and ajp
• Suggestions:
– Set enableLookups to false
– Make sure maxThreads and acceptCount are set
sufficiently high (but not so high that you’re accepting
more traffic than your Tomcat instance can handle)
– compression trades off bandwidth and processing time
27
Alternatives to the Classic
Java Blocking Connector
• NIO
– New input/output
– Supported starting in Tomcat 6
– Provides access to low-level I/O operations of modern operating
systems, including multiplexed, non-blocking I/O and polling
• APR connector (Apache Portable Runtime)
– Tomcat 5.5.15 and later (reliably)
– Uses OpenSSL
– Native code and thus faster
• Bottom of http://tomcat.apache.org/tomcat-6.0doc/config/http.html has a good comparison
28
Building the Native Connectors
• Dependencies
– OpenSSL (you need the source) - 0.9.8a or later
– APR (on Red Hat and variants, apr-devel RPM is
sufficient) - 2.2 or later
• Steps:
– Locate or download APR
– Download OpenSSL (you do need the source)
– Unpack the native connector
29
Building the Native Connectors
• Steps (continued)
– ./configure --with-ssl=[path to extracted SSL] -with-apr=[path to apr-1-config, possibly
/usr/bin/apr-1-config]
– make
– make install
– Update setenv.sh to use the built library
CATALINA_OPTS="$CATALINA_OPTS Djava.library.path=/usr/local/apr/lib"
30
Building the Native Connectors
• Steps (continued)
– configure the APR connector(s) in server.xml
– Update protocol attributes:
• HTTP:
org.apache.coyote.http11.Http11AprProtocol
• AJP: org.apache.coyote.ajp.AjpAprProtocol
– Optionally, configure SSL and set up the APR
https connector
31
Building the Native Connectors
• Sample APR SSL connector
<Connector
protocol="org.apache.coyote.http11.Http11AprProtocol"
port="8443" minSpareThreads="5" maxSpareThreads="75"
enableLookups="true" disableUploadTimeout="true"
acceptCount="100" maxThreads="200" scheme="https"
secure="true" SSLEnabled="true"
SSLCertificateFile="/usr/local/ssl/server.crt"
SSLCertificateKeyFile="/usr/local/ssl/server.pem"
clientAuth="false" sslProtocol="TLS"/>
32
Monitoring Database
Connection Pools
• Can be done via /Catalina/DataSource in the
MBeans tree within JConsole
• Parameters for your pool are shown at
http://commons.apache.org/dbcp/configuration.ht
ml
• Be sure to make your pool large enough for the
traffic you anticipate
• Be sure to time out requests for connections
• Consider removing abandoned connections
33
Other Suggestions
• Turn off JSP development mode in production by setting
the development parameter of the jsp servlet to false
– Keeps JSPs from being checked for modification
• Scale back access and error logging to just what’s needed
• Consider precompiling your JSPs – see
http://tomcat.apache.org/tomcat-6.0-doc/jasperhowto.html#Web%20Application%20Compilation
34
In Closing
• Thank you for joining me!
• Please email me at
[email protected] with
questions
• Good luck with tuning Tomcat! 
35