Monitoring Tomcat Performance: Tips And Tricks

Monitoring Tomcat performance is crucial for the smooth functioning and availability of software applications. It enables engineers to gauge system health in real time, quickly establish the context of the underlying issue, and predict potential malfunctions.

Tomcat is an open-source web server and servlet container used to run Java-based HTTP applications. It is one of the most widely-used servers in the realm of Java-based web applications.

- Memory usage

- Uptime

- Response time

- Error rates

- Request throughput

- Number of sessions

- Garbage collection

There are two main ways to monitor Tomcat performance: using Java Management Extensions (JMX) beans or a dedicated monitoring tool such as MoSKito or JavaMelody.

Memory usage

The general rule of thumb is to avoid your operating system swapping the memory needed by the JVM. This will result in a very slow JVM, which will slow down Tomcat and the applications running inside it.

The initial memory size, maximum heap size, and used memory size are key metrics to monitor. The initial memory size is the initial amount of memory requested by the JVM during startup. The maximum heap size is the maximum amount of memory that the JVM will be assigned by the operating system. The used memory size is the amount of memory currently used by Tomcat and the JVM it runs on.

It is generally recommended to set the same value for the initial memory size and maximum heap size to ensure that there is enough memory for the maximum to be reached during the lifetime of the Tomcat process. If the maximum heap size is exceeded, the process will fail to start.

The used memory heap size is the key metric to watch and set alerts for. The alert threshold will depend on the garbage collector being used, but for newer garbage collectors, the heap memory should ideally stay below 85-90%.

It is also useful to monitor Tomcat logs as they can help detect out-of-memory errors, which indicate memory issues such as a heap size that is too low or memory leaks in the application.

The garbage collector is responsible for cleaning up discarded objects to free up memory. It is important to monitor the collection count and collection time, especially for any spikes, as this may indicate inefficient code or memory leaks.

To monitor memory usage for the Tomcat JVM, you can use JMX. However, note that this will give you the memory usage for Tomcat and all deployed web apps combined. To get memory usage for a single web app, you would need to use a more sophisticated application server or a separate Tomcat instance per web app.

There are also various monitoring tools available that provide Tomcat memory usage monitoring, such as ManageEngine Applications Manager, SolarWinds Server & Application Monitor, Site24x7 Infrastructure Monitoring, Sematext Apache Tomcat Monitoring, Nagios, Zabbix, Tomcat Manager, JavaMelody, JConsole, AppDynamics, Datadog, Dynatrace, and ManageEngine Applications Manager.

Uptime

Another option is to use a script, such as the one provided by ElevatiTech on GitHub, which monitors and reports the status code of the Tomcat process to Amazon Web Services (AWS) CloudWatch. This script is designed specifically for AWS EC2 instances and requires the installation of awscli. By running the script and configuring cron jobs, you can collect Tomcat uptime data on CloudWatch and set alarms to alert you in case of downtime.

Response time

The GlobalRequestProcessor MBean (Catalina:type=GlobalRequestProcessor,name="http-nio-8080") provides the requestCount and processingTime metrics, which are essential for monitoring response time. The requestCount metric indicates the number of requests your server receives over time, while the processingTime attribute represents the total time Tomcat spends processing requests during its entire runtime.

By monitoring these metrics, you can gain insights into how your server is performing during peak and off-peak hours. For example, if you notice a sharp increase in processing time during peak hours, you may need to increase the number of threads allocated for handling requests.

Additionally, you can retrieve the processing time of individual requests by analysing Tomcat logs, which document the HTTP method, status, and total processing time for each request. This detailed information can help you identify specific requests that are taking longer to process and optimise them accordingly.

Another important metric related to response time is maxTime, which indicates the longest time it takes for the server to process a single request. Monitoring this metric can help identify requests that are taking an unusually long time and may require further optimisation.

To gain a comprehensive understanding of response time, it is also crucial to monitor thread usage. Tomcat uses worker threads to process requests, and the number of available threads directly impacts the server's ability to handle requests simultaneously. The ThreadPool MBean (Catalina:type=ThreadPool,name="http-nio-8080") provides metrics such as currentThreadsBusy and maxThreads, which offer insights into thread utilisation for each connector.

By monitoring the correlation between currentThreadsBusy and maxThreads, you can fine-tune your thread pool configuration. For instance, if you consistently observe that the number of busy threads reaches or exceeds the maximum number of threads, you should consider increasing the maximum number of threads allocated.

Furthermore, monitoring tools like JavaMelody provide visual representations of response time data through graphs and charts. For example, JavaMelody's "HTTP hits per minute" graph allows you to isolate HTTP requests and analyse their response times. This can help identify specific types of requests that may be contributing to longer response times.

In summary, monitoring response time is vital to ensure a positive user experience. By utilising the available metrics, tools, and MBeans, you can optimise your Tomcat server's performance and ensure that your application responds to requests efficiently and without significant delays.

Error rates

• OutOfMemoryError: This error occurs when the Java Virtual Machine (JVM) runs out of memory. It is usually indicated by an exception such as "java.lang.OutOfMemoryError: Java heap space". Monitoring the HeapMemoryUsage metric can help identify memory issues and prevent OutOfMemory errors.
• Server-side errors (5xx): These errors indicate that the server is unable to process a request. They could be caused by various factors such as memory leaks, high CPU usage, or issues with the application code.
• Client-side errors (4xx): These errors indicate problems with the client's request, such as insufficient permissions or missing files/pages. While they don't indicate critical problems with the server, they can impact the user experience.

To monitor error rates, you can use tools such as Tomcat Manager or JavaMelody, which provide access to Java Management Extensions (JMX) beans. The GlobalRequestProcessor MBean (Catalina:type=GlobalRequestProcessor,name="http-nio-8080") includes the errorCount attribute, which represents the cumulative number of errors encountered against incoming requests. Additionally, you can monitor Tomcat's access logs to get more detailed information about each error, including the HTTP status code, processing time, and request method.

By tracking error rates and correlating them with other performance metrics, you can gain valuable insights into the health and stability of your Tomcat server and deployed applications.

Request throughput

The Catalina:type=GlobalRequestProcessor MBean provides the requestCount metric, which indicates the number of requests received by the server over time. This information can be used to adjust thread counts and other configurations to optimise performance. For example, if requestCount decreases sharply without a corresponding change in processingTime, it may indicate that worker threads are being occupied by bugs even when they should be idle.

The processingTime metric, also provided by the GlobalRequestProcessor MBean, represents the total time spent processing all requests since the server started running. It is beneficial to use a monitoring tool to measure this value as a rate over a shorter time frame, such as an hour or a day, to understand how the server is performing during peak hours.

The maxTime metric indicates the maximum time it has taken for the server to process a single request. Monitoring this metric can help identify requests that are taking too long to process, which could be due to a slow-loading JSP page or a time-consuming associated process.

By monitoring request throughput metrics, administrators can ensure that the Tomcat server is handling requests efficiently and make adjustments as necessary to improve performance.

Frequently asked questions