TomcatExpert

Daniel Mikusa's blog

Blog : Using the Tomcat 7 JDBC Connection Pool in Production

posted by dmikusa on January 23, 2012 03:14 PM

One of the new features with Tomcat 7 is a replacement to the commons-dbcp connection pool. While the commons-dbcp connection pool works fine for small or low traffic applications, it is known to have problems in highly concurrent environments (think multi-core/multi-cpu).

Fortunately, this is where the JDBC Connection Pool excels. It is a completely new connection pool which has been written from the ground up, with a focus on highly concurrent environments and performance.

Given its focus on high concurrency and performance, many users are finding that the JDBC Connection Pool can be great for use in a production environment. This article will discuss the features and options which make using the JDBC Connection Pool a great choice.

The Basics

Getting started with the JDBC Connection Pool is very simple. It was purposefully designed as a drop-in replacement for commons-dbcp and as such, if you've ever used commons-dbcp you'll be immediately familiar with the configuration for the JDBC Connection Pool.

This means the most existing commons-dbcp users can switch to the JDBC Connection Pool by simply adding the following property to their configuration factory=”org.apache.tomcat.jdbc.pool.DataSourceFactory”.

What about the other commons-dbcp configuration options? You don't need to change them at all. Virtually all of the commons-dbcp configuration options are supported by the JDBC Connection Pool. Including but not limited to: testWhileIdle, testOnBorrow, testOnReturn, maxActive, minIdle, maxWait, initialSize, removeAbandoned, removeAbandonedTimeout and logAbandoned.

Read More

42 comments   |  

0
Rating
  |  

Operations | jdbc-pool, Apache Tomcat 7

Blog : Performance Tuning the JVM for Running Apache Tomcat

posted by dmikusa on November 22, 2011 09:13 AM

This article is the second in a series discussing how to performance tune the JVM to better run Apache Tomcat. In the first article, we discussed the basic basic goals and how to monitor the performance of your JVM.

If you have not read the first article, I would strongly suggest reading that before continuing with this article. It is important to understand and follow the processes outlined in that article when performance tuning. They will both save you time and prevent you getting into trouble. With that, let's continue.

Tuning the JVM

At this point we've covered the basics and are ready to begin examining the JVM options that are available to us. Please note that while these options can be used for any application running on the JVM, this article will focus sole only how they can be applied to Tomcat. The usage of these options for other applications may or may not be appropriate.

Note: For simplicity, it is assumed that you are running an Oracle Hotspot JVM.

Read More

310 comments   |  

0
Rating
  |  

Developers, Operations | Tomcat Configuration, Tomcat Performance

Blog : Setting Up Measurement of Garbage Collection in Apache Tomcat

posted by dmikusa on November 16, 2011 08:15 AM

Have you ever seen this scenario before? A user has deployed an application to a Tomcat server. The application works great during testing and QA; however, when the user moves the application into production, the load increases and Tomcat stops handling requests. At first this happens occasionally and for only 5 or 10 seconds per occurrence. It's such a small issue, the user might not even notice or, if noticed, may choose to just ignore the problem. After all, it's only 5 or 10 seconds and it's not happening very often. Unfortunately for the user, as the application continues to run the problem continues to occur and with a greater frequency; possibly until the Tomcat server just stops responding to requests all together.

There is a good chance that at some point in your career, you or someone you know has faced this issue. While there are multiple possible causes to this problem like blocked threads, too much load on the server, or even application specific problems, the one cause of this problem that I see over and over is excessive garbage collection.

As an application runs it creates objects. As it continues to run, many of these objects are no longer needed. In Java, the unused objects remain in memory until a garbage collection occurs and frees up the memory used by the objects. In most cases, these garbage collections run very quickly, but occasionally the garbage collector will need to run a “full” collection. When a full collection is run, not only does it take a considerable amount of time, but the entire JVM has to be paused while the collector runs. It is this “stop-the-world” behavior that causes Tomcat to fail to respond to a request.

Fortunately, there are some strategies which can be employed to mitigate the affects of garbage collections; but first, a quick discussion about performance tuning.

Read More

578 comments   |  

4
Rating
  |  

Developers, Operations | Tomcat Configuration, Tomcat Performance

Syndicate content