Trusted by leading companies
The Apache Tomcat software is an open-source implementation of the Java Servlet, JavaServer 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 and can be used as a standalone HTTP server. According to a Plumbr survey, Tomcat is the most favored choice for deploying highly transactional Java applications and services, with close to a 70% market share.
To ensure the availability and performance of such applications, performance 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.
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:
| 7 Key Areas for Tomcat Performance Monitoring |
|---|
There are many ways to monitor a 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.
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.
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:
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).
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.
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.
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.
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:
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.
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 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.
Monitor Real User Experience for Web Applications
Learn more
Monitor Java application performance without any code changes
Learn more
