You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 20 Next »

How do I make Tomcat startup faster?

This section provides several recommendations on how to make your web application and Tomcat as a whole to start up faster. Before we continue to specific tips and tricks, the general advice is that if Tomcat hangs or is not responsive you have to perform diagnostics. That is to take several thread dumps to see what Tomcat is really doing. See Troubleshooting and Diagnostics page for details.

The Servlet 3.0 specification introduces support for

  • javax.servlet.ServletContainerInitializer (shortened as SCI)
  • Web fragments (META-INF/web-fragment.xml)
  • Using annotations to define components of a web application (Servlets etc.)
  • Using annotations to define components processed by an SCI (@HandlesTypes annotation on a SCI)
  • Packing web application resources in jar files (META-INF/resources/*)

These features are collectively referred as "plugability features" and are there to simplify plugging of additional frameworks into a web application. See chapter 8 of Servlet 3.0 specification for details.

These features require scanning the JAR files. The worst is scanning for annotated classes. There are a lot of class files to process and parsing a class file takes noticeable time.

It is possible to configure a web application to omit most of the scanning. It is also possible to configure which JARs Tomcat should skip.

Other features that require scanning are:

  • Discovery of tag libraries. That is scanning for Tag Library Descriptor files (META-INF/**/*.tld) (shortened as TLD scanning)

The TLD scanning is done at startup, because a library can define a Listener in its TLD file.

A note: in Tomcat 7 and earlier the TLD scanning happens twice, (1) by servlet engine to discover the listeners, (2) by JSP engine when compiling a JSP page. The first scanning happens at startup time (in TldConfig), the second one happens when Tomcat needs to compile a JSP page (in TldLocationsCache). The second scanning is more noticeable, because it prints a diagnostic message about scanned JARs that contained no TLDs. In Tomcat 8 the TLD scanning happens only once at startup time (in JasperInitializer).

Remove unnecessary JARs

Remove any JAR files you do not need. When searching for classes every JAR file needs to be examined to find the needed class. If the jar file is not there - there is nothing to search.

Note that a web application should never have its own copy of Servlet API or Tomcat classes. All those are provided by the container (Tomcat) and should never be present in the web application. If you are using Apache Maven, such dependencies should be configured with <scope>provided</scope>. See also a stackoverflow page.

Configure your web application

There are two options that can be specified in your WEB-INF/web.xml file:

  1. Set metadata-complete="true" attribute on the <web-app> element. 2. Add an empty <absolute-ordering /> element.

Setting metadata-complete="true" disables scanning your web application and its libraries for classes that use annotations to define components of a web application (Servlets etc.). The metadata-complete option is not enough to disable all of annotation scanning. If there is a SCI with a @HandlesTypes annotation, Tomcat has to scan your application for classes that use annotations or interfaces specified in that annotation.

The <absolute-ordering> element specifies which web fragment JARs (according to the names in their WEB-INF/web-fragment.xml files) have to be scanned for SCIs, fragments and annotations. An empty <absolute-ordering/> element configures that none are to be scanned.

Note: in Tomcat 8 the container-provided SCIs are always discovered, regardless of absolute-ordering. It does not prevent scanning for annotations, but the list of JARs to be scanned will be empty, and thus it will complete quickly. The classes in WEB-INF/classes are always scanned regardless of absolute-ordering. An example of a container-provided SCI is in the WebSocket API implementation jar (tomcat-websocket.jar, tomcat7-websocket.jar) which is included with Tomcat 7 starting with 7.0.47. If you do not need support for WebSockets, you may remove it.

Scanning for web application resources and TLD scanning are not affected by these options.

See also a chapter in Tomcat 7 migration guide.

Exclude JARs from scanning

In Tomcat 7 JAR files can be excluded from scanning by listing their names or name patterns in a system property. Those are usually configured in the conf/catalina.properties file.

In Tomcat 8 you can use a system property or configure a <JanScanFilter> element in the context file of your web application.

Entropy Source

Tomcat 7+ heavily relies on SecureRandom class to provide random values for its session ids and in other places. Depending on your JRE it can cause delays during startup if entropy source that is used to initialize SecureRandom is short of entropy. You will see warning in the logs when this happens, e.g.:

<DATE> org.apache.catalina.util.SessionIdGenerator createSecureRandom
INFO: Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [5172] milliseconds.

There is a way to configure JRE to use a non-blocking entropy source by setting the following system property: -Djava.security.egd=file:/dev/./urandom

Note the "/./" characters in the value. They are needed to work around known Oracle JRE bug #6202721.

Also note that replacing the blocking entropy source (/dev/random) with a non-blocking one actually reduces security because you are getting less-random data. If you have a problem generating entropy on your server (which is common), consider looking into entropy-generating hardware products such as "EntropyKey".

Starting several web applications in parallel

With Tomcat 7.0.23+ you can configure it to start several web applications in parallel. This is disabled by default but can be enabled by setting the startStopThreads attribute of a Host to a value greater than one.

Memory

Tweak memory parameters - Google is your friend.

Config

Trim the config files as much as possible. XML parsing is not cheap. The less there is to parse - the faster things will go.

Webapp

  1. Remove any webapps you don't need. (So remove the all the webapps installed with tomcat) 2. Make sure your code is not doing slow things. (Use a profiler)

CategoryFAQ

  • No labels