Tomcat/Cocoon Performance on Production Sites?

Saqib Ali asks: "A Tomcat/Cocoon setup can be used as a framework for publishing XML content. I have this setup running in testing environment for about 5 months now, and would like to move it into production. Is anyone using a similar setup and can comment on Tomcat's ability in handling the load from a production environment, or should we look at other Java Servlet engines like BEA, Jetty or Resin? If Open Source solutions can't work under these kind of pressure what should we be looking at in terms of different commercial solutions for publishing XML content?" A similar question with respect to Tomcat and Jetty was discussed in this previous discussion. What effects does using Cocoon have on Tomcat-based environments?

Comments

Tomcat runs fine

[Tomah4wk]

Ive had multiple tomcat servers running on a sunfire E6800 (24 processor, 32GB ram etc..) under solaris using j2ee 1.3 and they have all been working fine, not one single server failure. One of which is a webapp server that has a variety of apps running on it, and the other is essentially an 'xml server' used for a varitey of applications (globus, grid computing etc). Theses are both based on tomcat 4.0, and there are some more running but i forget which version of tomcat they use

Caucho's Resin

[Pengo]

I have taken 2 production environments from Tomcat to Resin.. I have Resin to be more robust and easier to develop w/than Tomcat for various reasons. (First and formost the error message points you strait to the line of JSP rather than the error code linking back to the servlet. Resin does have some performance perks over Tomcat, but unless it's a VERY high volume site w/lots of load balanced servers, it's not going to probably matter much.

The thing I would say #1 is what you know. I know Resin inside and out, and when something goes wrong.. I know how to deal with it. Tomcat, I can't say the same thing. For this reason, it's been well worth the 500 dollars per server to deploy resin, as it's cheeper for us to maintain.

But, I have been working with resin for 3 some years now.

If tomcat works for you, go for it.. if it holds up under the stress tests , etc.. use it! :) You have had it in testing for a LONG time, at least by my experience..

Good luck either way, but if you do look to a commercial product, definately give Resin a serious look. http://www.caucho.com

jrockit

[galore]

one of the simplest tomcat performance improvements i've made is by switching from sun's vm to bea's jrockit. jrockit is free to use, and in my experience a much more robust server side environment. it's faster, has more flexible garbage collection options, and a nice gui management console. it helps to have a lot of memory (i think by default it will use 75% of the available system memory), but for some of the webapps i've built, i've seen tomcat+jrockit turn out 15-20% more pages/sec than tomcat+hotspot. jrockit 8 beta came out recently; it supports jdk-1.4 and has been solid for me (so far) running tomcat, jetty, and jboss. i've even been using jrockit on my personal workstation while developing with jboss because it cuts the startup time from about 1m:45s to 50s.

http://www.bea.com/products/weblogic/jrockit/ind ex .shtml

other than that, i've found a big tomcat performance problem to be that of spawning new threads. the default connector's configuration sets minProcessors=5 (ie: 5 threads in the threadpool available to handle new requests). i find that when load is high enough to warrant more than the number of initial threads, requests get dropped on the floor while more threads are added to the pool. so don't be shy about starting enough request processors from the beginning.

also, don't be afraid to run some load tests on your app while profiling. you'll need a fast machine to run tomcat+cocoon under a profiler, but the results are often very helpful in finding bottlenecks. in particular, you'll probably find a lot of time spent in StringBuffers, which is normal for an app like yours, but it's a good place to start when you're interested in shaving a few seconds here and there.

hope that helps a little.

Re:jrockit

[galore]

when i say that a lot of time is spent in StringBuffer i am referring to the concatenation of Strings (or primitive types converted to Strings). String concatenation is obviously a big part of servlet engine (just take a look at the .java file generated by your preferred jsp compiler). String concatenation with the + operator is equivalent to calling the StringBuffer.append method (thanks to the compiler). concatenating Strings across multiple statements is not equivalent to just calling .append multiple times. for each statement a new StringBuffer is allocated, which is costly, and then shortly gc'd, which is also costly.

for example:

String s = "one" + "two" + "three";
return s;

is roughly equivalent to:

StringBuffer sb = new StringBuffer("one").append("two").append("three");
return sb.toString();

whereas

String s = "one";
s += "two";
s += "three";
return s;

is roughly equivalent to:

StringBuffer sb = new StringBuffer("one").append("two");
String tmp = sb.toString();
sb = new StringBuffer(tmp).append("three");
return sb.toString();

the second set of statements requires more allocation and garbage than the first, and this is the optimization i'm referring to. if you have an idea of the target size of the finished StringBuffer, it's also helpful to declare the initial size of the internal buffer with:

new StringBuffer(int size)

obviously optimizations of StringBuffers or other similarly basic methods (equals, hashCode, etc) are important in gaining every last ounce of efficiency, but i'm also not saying this is the only way, or even a good place to start. architectural efficiencies will probably make the most crucial difference, so start there before profiling your StringBuffers :)

Re:jrockit

[dubl-u]

StringBuffers should be used unless features of String are needed

Better still, use the Writer or the OutputStream. If you're just using a StringBuffer to pile up output before sending it, it's better for your CPU and your RAM usage if you just write the stuff out.

AxKit

[Matts]

You might want to consider Apache's AxKit. While parts of AxKit are written in Perl to make it faster for us to write, the key parts that do the heavy lifting are written in C for performance reasons. Some fortune 500 companies are already running their site on it, and we get an awful lot of people coming to us from Cocoon for performance reasons.

It's a full apache project (under the XML umbrella), just like Cocoon is, and incorporates the same technologies (XSLT and XSP), but a lot of people skip over it because it's not Java. Maybe now is time to re-evaluate that decision.

Yes, for about a year now

[arthurs_sidekick]

The site in question gets about 60-655K hits/day running in a 2x1.13GHz PIII/1GB RAM running Linux ( 2.4 series) with JDK 1.4 using an Apache front-end for SSL. We run Tomcat 4 and Cocoon 2, making judicious use of caching (we serve pre-transformed HTML pages generated from Docbook XML sources), but every page is dynamically generated. Haven't yet seen anything that makes me think we'll need anything beefier in the near future.