Tomcat Seminar

I attended Wednesday’s SpringSource Tomcat Seminar. Spring Source has a product based on Tomcat (Spring tc server). As a way of promoting this, they put on a brilliant seminar featuring Filip Hanik about deployment, performance and troubleshooting of Tomcat. The promotion of TC Server took about 20 minutes of a 4 hour seminar. The format was well thought out: “Here are are some really interesting ways Tomcat can be used, here are the command line tools to do it by hand, and finally, here is our product that helps automate and organize some of these things.”

Information came at such a rapid pace that I barely had time to write down keywords. He did NOT simply read from the slides like a dolt. Here are the slides.

• setenv isn’t documented, but when Tomcat starts, it looks for a file called setenv.sh|bat for instructions about which jvm to use and which Tomcat version to use. A default Tomcat install has no setenv.sh|bat and so defaults are used. For example the default JAVA_HOME is the java home in your system environment variables. Well, shit. All these years I’ve been changing my system’s JAVA_HOME when I could have been fixing setenv.
• supports variables like {port} in configuration files. This means you can have one server.xml file with a variable parameter for port, and the port is defined by which Tomcat instance you feel like starting that day. This is a huge advantage in staging and testing environments as you could be testing with multiple Tomcat versions and java versions.
• Hanik voiced skepticism about the wisdom of hot redeployment in production: failure to explode war files fast enough, memory problems, and problems with serialized sessions were all offered as reasons for this.
• Performance
  1. Logging Affects performance. Logging too much can eat up memory. For production environments, one should disable duplicate loggers.
  2. maxThreads. If CPU useage is low, Tomcat is not taking advantage of hardware and you should increase thread count. By the same argument, if CPU usage is high, lower maxThreads.
  3. maxKeepAlives. KeepAlives are simply keeping TCP connections alive so the handshake does not have to happen again. This setting governs how many requests are allowed from one TCP session. This is especially important if using SSL since handshakes are more costly there.
  4. ConnectionTimeout. How long without activity before a connection is terminated.
  5. AcceptCount: This is a setting that in a way caches a bunch of TCP/IP handshakes. There is also an Operating system level setting for this same activity.
  6. For the most part, tuning Tomcat itself is limited. Tweaking Tomcat won’t do much good if your application is not tuned. The JVM and Operating System need some attention too.
  7. Send and Recv buffers, set at Operating System level, are key to performance tuning.
  8. Garbage Collection affects performance. Heh. That sentence hides the existence of the field of Garbage Collection-ology. He sped through ways to debug garbage collection
• Troubleshooting
  1. We already know that the errors that end up in Catalina.out are those that are not caught by our applications. But, we can configure the way that errors are reported by Tomcat. For example, outOfMemoryException could be any one of 15 errors, but by default Tomcat will just report outOfMemoryException. With a simple command in the startup options for Tomcat, we can tell Tomcat to sift through the error types and take different actions depending on the errors. For example, make a heap dump when
  2. Heap Dumps and other info can be had with Java’s VM arguments such as XX:-HeapDumpOnOutOfMemoryError. Many more are here: http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp
  3. Thread Dumps are very informative. They can show deadlocks. Use kill -3 or Jstack. Java 1.6 has jstack built in.
  4. Profilers: The act of observation changes the thing you’re observing. Profilers will affect your code execution. To minimize the change in outcomes while you do detective work, it is advised to wait until you narrow down the problem before bringing profilers in.

Related Posts

1. SQuirrel SQL Client