Top Apache Tomcat Performance Metrics to Track and Monitor

In this guide we have put together the 7 top Apache Tomcat performance metrics that we think everyone should be monitoring. This is based on our two decades of experience of working with Tomcat to tease out every last performance boost that we can. By proactively monitoring these metrics you will be able to troubleshoot performance problems before your end-users notice.

What is Apache Tomcat?

The Apache Tomcat software is an open-source implementation of the Java Servlet, Java Server Pages (JSPs), Java Expression Language and Java WebSocket technologies. Tomcat is often used as a backend application server that connects to other web-facing servers like Apache and Microsoft IIS. Tomcat also includes its own native HTTP connector that allows it to be used as a standalone HTTP server. According to a Plumbr survey, Tomcat is by far the most favored choice for deploying and hosting highly transactional Java applications and services, with close to a 70% market share.

To ensure the availability and performance of such applications, Tomcat monitoring is essential. In this blog, we discuss the top seven areas that performance monitoring solutions need to cover so IT operations teams have the insights they need to proactively monitor the performance of a Tomcat application server and the applications hosted on it.

The Architecture of an Apache Tomcat Server

To determine the key areas we need to focus on to get the best performance out of a Tomcat server, let’s look at the Tomcat architecture. The key components are:

• Connectors, which are Tomcat’s links to the outside world, allowing the Catalina engine to receive requests, pass them to the correct web application, and send back the results through the Connector as dynamically generated content.
• The Engine represents the request processing pipeline for a service. All requests received by the Connectors are handled by the engine. While static pages are served directly from the server’s cache, dynamic pages will involve processing servlets and JSPs by the Tomcat engine.
• Context represents a web application. Each Tomcat instance may have multiple web applications and, hence, multiple contexts.
• Connection pooling support in the Tomcat server allows applications to connect to a backend database to execute queries. Instead of opening individual connections for each request, by using connection pooling, applications can minimize the number of connection opens and closes to the database server, thereby reducing the load on the database server and improving application response times to the users.
• Last but not the least, the Tomcat server runs on a Java virtual machine (JVM) and relies on the JVM for memory management, threading, garbage collection and so on.

#1 Tomcat Availability and Responsiveness from an External Perspective

There are many ways to monitor an Apache Tomcat application server. Java Management Extension (JMX) interface can be used to collect metrics about the server. Application logs can be monitored to determine errors that happen. The application process can be tracked to determine times when the server restarted. However, no matter how well the application server is monitored, there are going to be gaps in visibility that can be gleaned by looking at the server from within, such as relying on its own logging and APIs.

For example, see the below image that shows how request processing in Tomcat works. Incoming connections are placed in an accept queue. An acceptor thread picks up connections from the accept queue and passes them to worker threads.

The number of worker threads configured in Tomcat is limited. When request processing in Tomcat is slow, more connections get placed in the accept queue. The length of the accept queue is bounded, so when the queue is full, new connections will be dropped by Tomcat. This can result in users seeing errors when they access the application hosted on Tomcat. Currently, there is no way to track the occupancy of Tomcat’s accept queue. Hence, it is important to monitor whether a Tomcat server is able to service inbound requests or not by simulating requests to the server and observing the response from the server. If the connection to the Tomcat server fails, chances are that the Tomcat server’s accept queue is full or it’s too small to handle the incoming workload.

#2 Worker Thread Pool Utilization

From the accept queue, requests are passed to worker threads. Worker threads are configured for different connectors as a thread pool. The pool configuration specifies the maximum number of threads that can be running in parallel for that pool and the minimum number of spare threads that Tomcat will maintain at any point in the pool. When all the threads in a thread pool are busy handling requests (i.e., busy threads are very close to the max threads configured), the acceptor thread will not process requests from the accept queue. During those times, users may see slowness or connection failures. IT operations teams need to keep an eye on the thread utilization of each thread pool in Tomcat to determine times when there are processing bottlenecks. When such bottlenecks occur, they have to determine if the thread pool configuration can be altered to increase the number of threads in the pool, or if additional Tomcat instances need to be spun up to handle the incoming load.

While thread pools in general are specific to each connector, an executor is a special type of thread pool that is shared across connectors. When executors are configured, it is important to monitor the utilization of the executor thread pools as well.

#3 Tomcat Server Workload and Processing Efficiency

It is the Tomcat server’s Catalina engine that performs all the processing of requests it receives. Hence, tracking the performance of the request processing engine is very important. Metrics that can be reported about the request processing engine include:

• Workload measures: Requests handled, data received and transmitted
• Processing efficiency measures: average processing time for requests, maximum time to process a request, and errors during processing

By tracking these metrics over time, IT operations teams can determine times when the Tomcat server is not able to cope with the workload it is receiving or when sudden errors have crept into the processing (possibly because of a change in workload).

#4 Workload and Processing Efficiency for Each Web Module

Web modules in Tomcat correspond to web applications. Multiple web modules can be configured to run on a Tomcat server. It is important to track the workload and processing efficiency measures described above for each web module. This way, when the Tomcat server is seeing a high request rate, or is processing requests slowly, administrators can see if the issue is specific to a web module or whether it is affecting all web modules. Understanding this can aid administrators to quickly troubleshoot and fix Tomcat performance issues.

#5 Servlet Performance

The structure of a web module is shown above to the right. A web module is created by assembling servlets, JavaServer Pages (JSP) files, and static content like Hypertext Markup Language (HTML) pages into a single deployable unit. Web modules are stored in web application archive (WAR) files, which are standard Java archive files. The core application logic is implemented in the JSP pages and servlet files on the server-side. When a web module is seeing a lot of requests, or its processing time is high, an immediate question is whether the increased traffic or slower processing is attributable to one or more servlets being processed. Monitoring tools for Tomcat provide insights into the requests handled by each and every servlet and the processing time of each servlet. Comparing the processing time across servlets, administrators can determine the areas of the web application that need to be optimized.

#6 Business Transaction Performance

Knowing that a particular servlet is taking time is useful, but an immediate next question is, “Why is the servlet taking time to execute?” Administrators would like to know the exact line of code that is causing slowness. They would also like to know if the slowness is in Java processing (e.g., expensive method calls) or whether it is due to an external call to a remote service (e.g., a REST API call to a payment processing service), or whether the slowness is caused by database processing and, if so, which query/queries are causing slowness. Getting to this level of detail requires deep dive into the application code. This is where business transaction tracing comes in. This is a common approach used by Java application monitoring tools, wherein the instrumentation API of modern JVMs is used to add byte-code instrumentation that captures all method calls in Java and external calls from the JVM. This capability provides administrators with the insights they need to discover and troubleshoot Java application slowness issues.

#7 JVM Performance

Since Tomcat runs on top of a JVM, monitoring of the JVM must be an essential part of any Tomcat application performance monitoring strategy. JVM performance metrics can be used to troubleshoot server-side bottlenecks and answer the following questions:

• Are the JVM heap and non-heap memory pools sized correctly?
• Are there any out-of-memory exceptions or memory leaks?
• When does garbage collection happen and how much memory is freed up each time?

Monitoring web modules and servlets as indicated above indicates bottlenecks in processing web requests. Many times, applications perform processing asynchronously, in the background. What if one or more of these background jobs causes bottlenecks in the JVM? Monitoring threads in the JVM, detecting synchronization issues and deadlocks in the JVM, and alerting regarding times when garbage collection is taking too much time, affecting processing of user requests by Tomcat, are also important.

Proactively Monitor Apache Tomcat Performance

It is essential to have a proactive monitoring tool in place to monitor all of the above seven key areas of Tomcat performance. Administrators can use these metrics to learn about Tomcat configuration issues and bottlenecks. Development teams can also benefit from the insights provided by these monitoring tools. They can identify which line of application code or which database query is causing application slowness.

eG Enterprise from eG Innovations offers 360° visibility into all aspects of Tomcat application performance. From a single pane of glass, administrators can see the performance of the Tomcat server, the underlying JVM, the server operating system, as well as the virtual or containerized environment in which Tomcat is running.