Tomcat Performance

Tomcat's basic status can be accessed via the url: http://localhost:8080/manager/status url. It shows the threads and the connections stats.

To see detailed tomcat statistics enable JMX beans for tomcat by adding following to setnev.sh - "-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.port=15555"

Then the MBeans for tomcat and your specific webapp/Servlet can be accessed via jconsole or JMXProxyServlet.
https://tomcat.apache.org/tomcat-7.0-doc/manager-howto.html#Using_the_JMX_Proxy_Servlet

You need to add following entries to conf/tomcat-users.xml to be able to access manager/status and manager/jmxproxy urls.

<role rolename="manager-gui"/>
<role rolename="manager-status"/>
<role rolename="manager-script"/>
<role rolename="manager-jmx"/>

 <role rolename="tomcat"/>
 <role rolename="role1"/>
 <user username="tomcat" password="tomcat" roles="tomcat,manager-gui,manager-status,manager-jmx"/>
 <user username="both" password="tomcat" roles="tomcat,role1"/>
 <user username="role1" password="tomcat" roles="role1"/>

Source: https://www.mulesoft.com/tcat/tomcat-performance

Tuning Tomcat Performance For Optimum Speed

Tomcat configuration is by default geared towards first time users looking for powerful, hassle-free, out-of-the-box functionality. However, when deployed in a real-world setting, where high server load can be expected and achieving the best possible peak load performance is vital, it is important to customize these default settings based on your site's needs.

This may seem like a daunting task, and it is certainly not a small one, but the good news is that Tomcat is a very configurable system, and by following a logical process of testing and implementation, you can vastly improve your site's performance.

Are you tuning Tomcat for performance? Tcat gives you deep visibility into the performance of your web applications, and allows you to save optimal configurations. Get new instances up and running with a single click. Try Tcat today!

Understanding Limits

While some of Tomcat's settings can be adjusted in a way that will increase any site's performance, the most beneficial techniques for increasing Tomcat's performance are need-specific - that is, they are geared towards making Tomcat perform in the best way for your site, based on factors such as the types of traffic you serve and the web applications your server runs.

Before getting down to business, let's take a look at the biggest limits on your site's performance. Three factors negatively impact Tomcat's performance more than any others - network delays, remote client latency, and application architecture.

Two of these factors - network delays and remote client latency - are for the most part unavoidable, although using a web server in front of Tomcat to serve static content will free up more power for dynamic content. Remote client latency can be mitigated by compressing content with Apache mod_zip or Tomcat's compression filter.

However, the largest increases in performance are directly related to the architecture of your web applications. Consequently, the first step towards streamlining Tomcat's performance is determining the needs of your site, and using benchmark tools to obtain a clear, comprehensive picture of your site's current performance.

Establishing a Benchmark

Before any improvements can be made, it is essential to establish an accurate benchmark of your site's current performance, so that any changes can be measured in a useful, quantifiable manner.

There are a wide variety of both commercial and free tools that you can use to measure Tomcat's performance. Two of the most effective, Apache Jakarta JMeter, and ab, an HTTP server benchmark tool provided by Apache, can be obtained for free on Apache's website, along with further documentation and more specialized benchmark tools.

To generate a high-quality benchmark, it is important to simulate the real world scenario in which your site operates as closely as possible. Your test system should be as close a match to your production system as possible. Use the same hardware, OS, and software, and populate databases with the expected real-world record load. Generate traffic that is characteristic of your real-world traffic - if you are expecting lots of human traffic, don't test your system with repetitive HTTP requests.

When running your benchmarks, make sure to include tests for any special situations such as short term traffic spikes or searches that return extremely large result sets. Your final tests should be run over a two to three day period, as factors such as variable JVM performance and Tomcat memory leaks may only expose themselves after a longer time period.

General Tuning Techniques

Now that you've established your benchmark, it's time to apply a few techniques that provide a general increase in performance for almost all Tomcat users. This will allow you to determine how much your application's architecture needs to be modified.

Tuning JVM

The proper Tomcat JVM configuration is essential for getting the most out of your server.

Before you start changing any settings, you should make sure that you have chosen the most logical JVM for your site's needs. There are a growing number of JVM vendors, and if you do not require any JDK-specific functionality, it is a good idea to run some benchmarks and see which solution gives you the best performance. Also, make sure to upgrade to the latest stable release of your JVM, as this may give you a sizable performance boost right away.

Next, consider experimenting with your JVM threading configuration. If your JVM supports both green and native threads, you should try both models to determine the best choice for your site. If you are running I/O bound applications, the native thread model should offer you improved performance. However, green threads will decrease the load placed on your machine. If you are unsure which option to choose, native threads are usually a good choice.

Certain JVM processes, such as garbage collection and memory reallocation, can be a drain on your server. You can reduce the frequency with which these processes occur by using the -Xmx and -Xms switches to control how JVM handles its heap memory.

JVM garbage collection can use up valuable CPU power that you want being used to serve web requests. To reduce the frequency with which JVM invokes garbage collection, Use the -Xmx switch to start the JVM with a higher maximum heap memory. This will free up CPU time for the processes you really care about.

To maximize the effectiveness of this technique, use the -Xms switch to ensure that the JVM's initial heap memory size is equal to the maximum allocated memory. This will keep the Tomcat JVM from having to reallocate and resize its heap memory, which will free up additional CPU cycles for Tomcat to serve requests. If your web applications can handle the possibility of lower total garbage collection throughput, you should try enabling incremental collection with -Xincgc.

If you need more information on the way your current configuration is handling your collection load, use -verbose:gc to capture performance data.

Configuring Connectors

Basing your maxThreads Connecter thread pool settings on an accurate estimation of your web request load is essential for getting the most out of Tomcat.

Values that are too small can leave you without enough threads to handle all your requests, and prevent Tomcat from effectively utilizing your server hardware to increase performance. Values that are too high significantly increase Tomcat's startup time, which is a critical issue at at peak traffic intervals. Experiment with different values to determine the best middle ground, and you should see an increase in performance.

Compression

By default, the compression attribute is set to off, but some applications perform better when it is switched to on. Try changing your settings and see what works best for your site. If you find that turning compression on increases your performance, make sure you use the compressableMimeTypes setting to specify what types of data you want compressed.

HTTP, HTTPS, and HTTPD

In general, using HTTP instead of HTTPS will result in much better Tomcat performance. However, HTTP may not be right for your site. If you require the security of HTTPS, despite its slow speed compared to HTTP, you may have to consider adding additional servers closer to your users to increase speed. The problem lies in the verbose traffic HTTPS generates during requests, which increases the overall serve time for users with higher pings.

Whatever you do, using Apache HTTPD to proxy your requests should be avoided at all costs, as it will decrease your performance by nearly 50%.

Web Servers For Static Content

Tomcat's major strength is dynamic content generation, and it will balance loads better if it is not responsible for anything else. Dedicating a web server in front of Tomcat to serve any static content your site requires is a quick way to free up more power to serve requests.

Stay Current

Every major Tomcat release is optimized for higher performance across the board. Taking the time to keep your version updated will save you big performance headaches in the future.

Tuning Your Applications For Performance

Now that you've done everything you can to customize Tomcat's configuration to match your needs, it's time to look at improvements to your application's architecture. This process is more complex, but the performance gains you will see are exponentially greater.

The best time to think about optimizing your application for better performance with Tomcat is during the development phase. Using tools such as JProbe or OptimizeIt to search for any bottlenecks due to thread synchronization will save you a lot of hassle when you deploy your application.

Additionally, read up on optimization techniques specific to each of your application's elements. If your database performance is slower than you'd like, consider using middleware to persist and cache objects. You'll see less thrashing of the JVM for creation, which means less garbage collection, and less db query latency. Consider factors such as the suitability of your protocol for the project. For example, if you are loading large amounts of data, and you need high performance, XML is the wrong choice.

Design your application to distribute work across the tools that do that work most efficiently. If you are serving dynamic pages that are in reality more static than dynamic, consider changing them to static pages and serving them with your web server to take some unnecessary load off of Tomcat.

If the page changes too frequently to make this option logical, try temporarily caching the dynamic content, so that it doesn't need to be regenerated over and over again. Any techniques you can use to cache work that's already been done instead of doing it again should be used - this is the key to achieving the best Tomcat performance. The most significant limits to performance are the demands of your web application, so consider all your design choices carefully.

Implement these techniques, and you're well on your way to great Tomcat performance.