Tomcat or Jetty or GlassFish
Before too long the company I work for is going to be putting a few websites up and part of the functionality will be running java webapps. At first I was just going to throw tomcat on the server and let it run. After all, Tomcat is almost the defacto standard for web containers so why not? Well after reading a few posts by Glen Smith I’m starting to rethink that.
I have some minor experience with Jetty and I like it, but have never used it in a production environment. To be honest, my knowledge on Glassfish is pretty light. I’ve heard about it, but never really took a look at it until today. I know that Tomcat has never really been known as a high performance engine but I’m curious as to what you might have to say on this subject.
The amount of traffic will be in the few million page views a month range on a dual CPU linux box with 8 gig of ram. The kind of traffic will be fairly light, meaning they aren’t doing any really hard processing, just a lot of it.
So all religious arguments aside, how to these perform against each other? (oh yes, I understand that Glassfish is a full JEE server and not just a web container.)
Suggestions? Thoughts? Experiences?
Don’t miss anything, subscribe!
Did you enjoy this post? Why not leave a comment below and continue the conversation, or subscribe to my feed and get articles like this delivered automatically to your feed reader.
Comments
Thanks Alexis. I’ve heard that the management console was quite good in Glassfish which is a definite plus. One blogger commented that he was able to set up multiple domains, change a bunch of settings and other stuff without every having to bring the server down, and the hot deploy worked really well too.
We did some extensive performance testing for an app early last year, tested Jetty5, a beta of Jetty 6 using NIO, and Tomcat 5. We found no appreciable difference in performance between the various containers except that for some reason the Jetty beta using NIO was much slower than the others (a shame we never got to revisit it to find out why). Our slowest link was by far the database, which we heavily optimized by background-queuing database activity (traffic was expected to be very spikey) using the Java5 concurrent APIs. We tend to migrate towards Jetty simply because we find it easier to embed into larger apps, purely personal preference, YMMV 
That is interesting Steve. While I have nothing myself, I’ve always heard that Jetty ran much faster than Tomcat. Maybe that was back in the 4.x days.
Thanks for the info!
From someone who works in a large webshop that handles static and dynamic content I’ve run some load tests on just the container aspect of things between Tomcat, Jetty, Resin and SunOne. Out of the three stand alone containers Resin won out on performance. When you start mixing in static content of html and images SunOne won. This was with SunOne 6.1. I haven’t had a chance to run the same set of tests against SunOne 7.0, but it has all the features mentioned above for hot deploy, mutiple domains, JMX, command line config changes and CLI deploys. I’m always surprised it gets left off of the list when people talk about the Tomcat, Jetty, Resin comparisons.
Just to make things clear, Steve is talking about the Sun Web Server. Version 7.0 was recently released. Excellent product indeed.
If you use glassfish on Linux I would recommend to test it well before you use it in production. We have tried to use SJAS/glassfish in Linux and it didn’t work well. It was using too many file descriptors and several times it’s http listener just stopped working, it was not responding to requests and without any error messages in log files. After all that struggle we just moved to jboss and we never had any problems after that.
That is something to be concerned about since we will be running on Red Hat Enterprise.
Steve, if you are still listening are you running on Solaris or Linux?
We are running Sun Web Server 6.1sp{blah} on Linux machines. If I had my preference we would be running on Sol x86, but that is out of my control. We did have to do tuning on the webserver and some kernel params to get performance where we would like it. Linux has some, er uh.. issues with heavily threaded applications. This has gotten better in the 2.6.x kernels though. We are working on a website redesign right now for one of our properties and I’m hoping to relaunch it on SWS 7.0.
Keep in mind that benchmarks don’t tell the whole story. Who cares that one app server can handle 10k hits a second vs 5k a second when you’re doing around 3 hits a second. More important is the monitoring abilities and also if there’s a way to scale up by adding more servers.
Also I would look at the track record of how quickly new java features are added to the app server. For how long were WebSphere users stuck on JDK1.3? When will they get 1.5 support?
That is a good point, especially about the new features. I think one of the things that kept BEA up there so long was they were first to implement the new specs so quickly. I’ve used WebSphere a lot in my previous job and it is so far behind it isn’t even funny.
I think comparative, relative benchmarks are good if they are close to your desired usage. For example, there was a popular/controversial benchmark put out by The Middleware Company a few years ago that while sparked a lot of communication about the J2EE vs. .Net results, the more interesting results were between the various java app servers. It didn’t take a genius to see that if you just looked at those results that WebSphere in that case really lagged behind.
Yes, TMC couldn’t publish the actual vendor names, but it didn’t take people too long to figure out who was who.
So yes, absolute numbers in benchmarks can be misleading, I think relative comparisons are good.
I’m biased, but we use Tomcat everywhere. We routinely benchmark against other servers, and it never loses. It might not win by a lot, but it always wins. People who claim Jetty is lighter or faster are just out of date: compare for yourself. Even on tangential metrics like binary distro download size and classes on the runtime path, Tomcat wins.
@Maris Orbidans: the file descriptor issue was indeed nasty. It was fixed back in December (GlassFish version 1ur1patch1).
OK, I’m biased, but I think you’ll find GlassFish to have good performance. Part of that is due to the Grizzly front-end (http://grizzly.dev.java.net).
Admin tools (CLI, WebUI, JMX) may also be a difference.
GlassFish v2 is about to hit beta. It’ll have clustering and load-balancing features integrated. Final version is scheduled for April. The current version is GF v1ur1 patch1.
You can also find some interesting info in these GlassFish production questionnaires: http://blogs.sun.com/stories/