Who is Using Tomcat or Jetty in Production?

JettyCatReady queries: "Ok, my company (a rather large, global financial institution) has recently blessed Linux for production use (woohoo!). Their position is that it will save them hardware costs to run on Intel machines instead of big IBM or Sun iron. No mention at all has been made of their position on open source. I'm part of a team that wants to make the case that the real savings are to be made by making use of things like Tomcat in place of BEA where we can (if all we want is JSP why pay a huge cost per server?). I even have a boss's boss who said in front of me, 'So I'm thinking, am I missing something by not using Tomcat? Do I have anything to lose?'"

"These are all excellent signs. The next step is to get an open source server into production. Tomcat is the natural choice because it's got the name recognition among Java app servers. Here's where I'm a little stumped. Whenever I mention the words 'Tomcat' and 'production' together, performance junkies come out of the woodwork and tell me that Tomcat sucks for production (what with it being a reference implementation and not optimized for speed). They say use Jetty (except for the ones that say to use Resin). The counter argument is that if my managers have heard of Tomcat, and seen vendors that will support Tomcat, and have never heard of Jetty, then there's no way they're going to bless it over Tomcat. (The same boss who praised Tomcat above also made a face when I mentioned JBoss. And I'm sure it has nothing to do with his personal experience with either.)

My question is, does anybody have some real world numbers of large institutions actually using these servers in a production environment? If somebody can tell me 'Company X uses Tomcat exclusively' then we would have no problem contacting company X and saying, 'So, what have your experiences been?' In other words I need leads, not actual white papers (although those would be nice, too). I need some real experiences, not just people who like Jetty over Tomcat because they don't like Sun."

My company uses tomcat exclusively

[Tet]

Like the subject says. It seems to work OK for us. Startup times are annoyingly slow. If we need to deploy a new context, then restarting tomcat brings with it a 30-45 second outage. But other than that, it's fine. Performance testing showed that increasing the number of threads the connectors can handle, and increasing the memory size (we use -Xmx500M) helps enormously.

Free application server from Sun

[MikeApp]

I know that you are probably looking for an open-source solution, but Sun has promised to release a free version of their application server this fall.

Sun "basic" application server [sun.com]

It will run on Linux.

Get away from Java

[Anonymous Coward]

Hmmm.. if you're got them on linux, you can also break away from the silly Java-does-everything culture. Common Lisp makes an excellent server-side tool, and is blazingly fast*, plus better OO than virtually anything else.

* People _still_ trot out "Lisp is slow", despite the fact that that reputation originated when 1MHz was fast... compiled lisp is certainly faster and less resource-hungry than any useful Java Virtual Machine I've seen.

If all else fails, test yourself

[Anonymous Coward]

I'm not a Java guy (I know the language and have written small apps, but it's not my primary or preferred language), so the answer to the following may be obvious to anyone with more Java experience, but...

How different are the implementations of each app server? If it only takes relatively small changes to be able to deploy some test code across multiple Java app servers, why not do a comparison between them with your company's own code (or a portion thereof)? That would be more accurate than a generalized benchmark (which, as we all know, can be manipulated to make any arbitrary product/implementation look better than the others).

For all I know, though, this may not be feasible if each app server requires vastly different deployments and application design to get the best bang out of each. Even if that is the case, it may actually be worth your while to spend some time up front to find out which app server would work best for your company. If the app servers do require significant changes in the applications, you're committing yourself to a platform that will not be easy to switch away from if it turns out to not suit your company's needs.

Any well managed project of moderate to large scales should involve some sort of product/platform/tool analysis anyway, or look to recent analyses for other similar company projects. Asking other people what app server they recommend will bring a lot of subjective comments. Best if you just grab the choices yourself and test to find which one will truly suit your company's need best.

Re:My company uses tomcat exclusively

[flipperboy]

My experience is almost exactly the same. We started using tomcat during development because it was free, and found that it performed well enough that we were confident moving into production with it. Restart times are not an issue for us; we can schedule resource drops for times when system use is minimized.

During load testing, we mucked about with the same tomcat parameters mentioned above, specifically thread count (starting and max) and heap size.

One last note: with versions 4.x of Tomcat, we've found that Tomcat is quick enough at serving up static content that we don't need to put Apache into the mix.

Tomcat does suck, avoid it.

[Epesh]

I've used Tomcat for testing against the Sun specs, and I find that it's slow and not worth the money you spend on it.

Yes, I know it's free. Pay attention.

It does a relatively poor job of implementing the spec itself, and the spec is supposed to be its reason for being. It's gotten faster over time, which is nice, but it's still not very good at handling things. Tweaks abound, but running a custom version of a servlet container isn't likely to bring comfort to you... I hope.

I'd suggest spending some money on the container, myself; Jetty [mortbay.org] is okay, but I personally prefer Orion [orionserver.com], which is fully J2EE, fast as all get out, and very, very easy to administer. Installation of an Orion instance takes three steps: unzip, copy tools.jar, java -jar orion.jar. Done. It's also free for development, so there's no per-seat license cost for you to use it to write code.

An aside: Oracle recently posted ECPerf numbers which were very good, and Oracle licensed the Orion codebase... and Orion costs thousands less. Since ECperf yields numbers based on dollars per transaction, you'd think Orion would kick butt on ECPerf.

I find Tomcat to be acceptable only for compliance testing, because so many people think it's the best that out there (because of the price point). I've spent a lot of time having to work around Tomcat; I'd hope you didn't feel like doing the same.

Comparisons, plus some opinions

[potcrackpot]

From my experience, Tomcat 4.x is faster than Apache and JServ.

Don't know how it compares to other servers (at least, from experience I don't), for example IIS, Resin, JRun etc.

Tomcat 3.x WAS very slow - for example, who had to combine Apache and Tomcat to get anything reasonable - using Tomcat for JSP and servlets, and Apache for static pages. This was in itself a bit of a nightmare. Tomcat 4 is miles better.

Comparing JRun to Tomcat for performance, see here [macromedia.com].

Compared to Orion and Resin, Tomcat also lost comprehensively [weblogs.com]. The arguments raged for a while over performance (for example [metronet.com])- but not many about whether it "did what it said on the tin".

A more serious point here is that your bosses care more about the name and image than the quality. I'd think about trying to convince them that this is Not A Good Idea. For someone who IS using Tomcat in production, just do a google search; you'll get quite a few, for example [eapps.com].

Rightworks used to use Tomcat....

[andawyr]

...in the catalog server. It wasn't serving up HTML per se:, but it was still used to run the application.

Since the catalog server was a major piece of the procurement software, it had to perform. If people can't populate their cart, then what's the point? This software was sold to various 'largish' companies without any complaint on the performance of the catalog....

I'm not sure what they're using now, since I bailed just before the .bomb meltdown...i2 bought the company, and we all know (!) where i2's stock price is - 0.71 yesterday. I'm not even sure if they're still selling the product, which would be a shame.

If the performance isn't good enough, throw a few caching proxies in front of the web servers. You may want to do that regardless of what web server software you run in the back end...

Re:My company uses tomcat exclusively

[Anonymous Coward]

I was one of the five developers who redid collegeclub.com from ASP to JSP. We had to build an infrastructure to handle the existing 300 million page views a month as well as be able to scale indefinately. Management would only let us go to a Java platform if they could see benchmarks showing performance as good as or better than their current IIS/ASP setup. We benchmarked Tomcat, Resin, and Orion. Tomcat just did not perform under the loads we needed; however, both Resin and Orion performed fine. We settled on Resin because at the time (maybe still are) they touted their software as open source (one of the big selling points of migrating from IIS). We did not kick Tomcat to the curb -- it is so simple to use that we keep it on each developer's machine as their isolated development environment. Hopefully it will continue to improve in the speed department. (And while I'm making wishes, hopefully someone will make an XMLDOM faster than MSXMLDOM!)

Try Resin

[peterdaly]

I run two production Servlet Containers. One is Tomcat 4.X, the other is on Resin. While Resin is not open source, the cost is only $500/server, which is quite low by J2EE standards. I believe it is free for development, but I could be wrong.

I tried Resin since I have heard "buzz" about it in message forums, and now can't say enough about it myself. Tomcat has a lot of quirks with reloading updated war files, reloading modified JSP's, etc. Resin does not have these problems, and I believe is much better suited for a non-stop production envirnment.

In Tomcat, it is not uncommon for me to have to restart the container when rolling out updates where certain things have changed. In Resin, I can even add or remove a JDBC Connection Pool from the resin.conf file and have to pool rolled out or back without any additional intervention from me. In short, it just works. Not only does it work well as far a few (if any) glitches, it is VERY fast as well.

For a commercial envirnment, I suggest you try Resin just to see if you find the value it adds over Tomcat worth it for you. I did.

-Pete

Details? Re:weather.com is now exclusively Tomcat

[Anonymous Coward]

please provide more details on the setup. eg. what type of RDBMS, if any, are you using? how are the boxes arranged for load balancing, clustering, etc. which flavor of linux?

we're architecting a large ASP product and considering a linux/apache/tc solution. any more details would be very helpful.

thanks!

Tomcat in production sucks!! (alas!)

[dario.lupi]

Ok guys, that's my experience. We had bad results with tomcat, our group of linux boxes (4 biprocessor pentium class machines RH 7.1) had big problems only with 60.000 pages on a day. What I appreciate less was the Tomcat ungraceful behaviour under stress. One moment all is Ok, after some seconds it starts trashing. We changed the code, installed Resin and achieve to serve 500.000 pages on a day with only 2 servers!!! Tomcat version was 3.2.something... Good luck!

Re:Production Tomcat

[rwinston]

I work for a major Telco, and recently we have made some sweeping and far-reaching decisions: 1) Our internal Web servers (including some servers that exist solely to serve Perl CGI scripts) are being migrated from NT/2000/IIS/ActiveState to Linux/Apache/mod_perl/Perl CGI. 2) Instead of using Oracle/SQL Server by default, we are beginning to use MySQL by default, and only use the big iron when its necessary. 2) We are using Tomcat for at least one production site, and perhaps more in the future. A lot of internal apps are being ported to Tomcat 4/mod_jk/Apache 2 This is not just a cost-saving exercise - this is going to solve some long-term reliability and security issues

Resin in a production environment, plus GLUE

[eyefish]

We've tested both Tomcat and Resin, and decided to go with Resin for several reasons.

First of all it is very stable and very fast. And secondly, it has a very comprehensive way to do clustering, fail-over, and distributed sessions management.

In just a couple of minutes you can set it up to cluster with several copies of Resin, each residing on a separate machine, on the same machine, or even in the same VM. You can even set up a Resin container to be a backup of another Resin container in the same machine, so you get both inter-machine and intra-machine failover.

You can also do distributed sessions in several ways (with TCP messages, database storage, etc), and you can even force a user session to stay within the same Resin container out of a clustered group.

As for Web Services, we heartly recommend GLUE from The Mind Electric. It's bar-none the absolute best (in terms of speed, stability, and easy of use) Web Services toolkit available for ANY platform. It puts Microsoft's .Net to shame, and it's way easier than offerings from IBM, Sun, Bea, Borland, or the Apache/Tomcat efforts. It's so easy to use that already you can make your *existing* applications be Web-Services compliant without re-writing or re-compiling them!!! You just tell GLUE which classes and methods will be exposed as Web Services and it automatically generates WSDL and starts listening for SOAP clients!!!

As for a database, try the latest non-beta version of mySQL. It supports row-level locking, full transactional support using innoDB, and it is fast (specially considering its price). (Note that postgress is also a good alternative).

Note that like many here, I also agree that Tomcat and JBoss are great solutions to your needs, so if your boss definitelly cannot be convinced otherwise, I think you'll be fine with Tomcat at least. I only advice you to design your applications in a way that they can cluster, so that you can increase performance easily by adding more Tomcat servers to the mix.

Jetty is optimized for speed

[gregwilkins]

Firstly It is not strickly true to say that tomcat does not look for speed. If anything it is a poor reference implementatin because it is trying to be suitable for production.

Jetty has been developed mainly as an efficient HTTP/1.1 server. The Servlet container is secondary to providing correct and efficient service of the protocol.

Jetty has been focused on being embedable in your application, rather than being a stand alone application server. Hence it is widely deployed but with very low visability. I wrote jetty and I'm still surprized when I find the jetty.jar inside IBM tivolli or Sonic MQ!

Re:BEA is buggy as hell anyhow.....

[Anonymous Coward]

Disclaimer: I am a BEA employee, but these comments are my own and do not represent my employer in any way.

Amen! I have been forced to run BEA and it has been agony. Plenty of things that run under Tomcat won't under WebLogic. IMHO, this just plain wrong! Afterall, isn't Tomcat the *reference* implementation?

I've heard this many many times -- if it works in Tomcat, why doesn't it work in WebLogic? Tomcat is the reference implementation!

Here's the deal -- Sun publishes the J2EE specifications. Tomcat, being the reference implementation, implements every feature in the JSP and Servlet specs. This allows Sun to demonstrate that the specification is workable.

Now, it is completely allowed for Tomcat to go above and beyond the spec -- for instance, they can implement their own tag libraries. This does not mean that having those tag libraries is required for the spec.

Tomcat follows the spec, it doesn't define it. Same with WebLogic -- we follow the same spec. As long as you code to the spec, your application will work on both WebLogic and Tomcat.

If you happen to find an area where WebLogic doesn't implement the spec, let us know. Software will always have bugs, and those bugs will need to be fixed. Making a list of bugs and posting them on /. is pretty silly and it's pretty one-sided. You didn't post how many of those bugs were fixed in later releases. I could write a book with all of the bugs Tomcat has had in it's lifetime, but it really doesn't make much sense if the majority of those are fixed, does it?

Re:JBoss

[alext]

I appreciate your concern, but I'm quite capable of judging the rival merits of WebLogic and JBoss.

I've worked with JBoss since before it was JBoss, and before it had any kind of support. I think it's fine as far as it goes, but your generalizations are not much more helpful than the original bit of flag-waving.

You appear to forget that some real customers are interested in things like usable security (not freeware Java SSL implementations), clustering that works with real hardware and centralized management for servers and applications.

These customers often also want to be in a position to handle future stuff like workflow and web services conveniently - not via 101 addons from different projects scattered around the web. This is what the Platform is giving them - the only competing strategy for this is from Microsoft.

If BEA were still selling 6.0 and had no coherent plan then you might have a point, but until JBoss has something that really is as comprehensive and functional there are going to be sufficient reasons for corporates to choose WebLogic.

I have shared your pain on the support side in the past (I've spent most of my time on the other side of the fence) but since the Web Support went live I've had no problem organizing things such as continuous, 24 hour attention to specific issues, with a problem being passed to engineers around the world in the middle of the night, and who I can talk to via one 800 number.

And for what it's worth, the BEA consultants I've worked with over here have been among the most clued up I've encountered from any organization. Unlike a lot of technology outfits offering consultancy, they tend to be old hands who can fix all kinds of stuff outside WebLogic - from routers to Solaris sys admin to Emacs init files - if the occasion demands. Sorry if your experience was different.

Reference Implementations

[rjamestaylor]

Regarding Tomcat's role as a reference implementation: for HTML, XHTML, XSLT, MathML, etc., the W3C commissions Amaya as the reference implementation, but I don't see people giving up IE or Mozilla for the lastest Amaya builds...nor have I heard, "Yeah, but how does it look in Amaya?," when reviewing a new site design. So, not knowing the world of Java Servers, I find the repeated cry of "reference implementation" a bit weak as a recommendation.

Re:JBoss

[togginho]

isn't it cute how men get caught up in their toys? :-) i'm not a fan of webLogic, and before alext runs me up against the wall, YES, i have worked with BEA and JBoss. as with everything in this get-exactly-what-you-need-world, there's a solution for every type of problem. why do people like JBoss? because it's stable enough to work, and free enough to be affordable. why do people like BEA? because of the reasons you mentioned. without products like JBoss, and the often-flamed open source software products, many, many people still wouldn't even know what a webapp deployment descriptor even is. the key to making new technologies work is to spread them, and WebLogic has never been good at that -- BEA used to be nothing but a transaction monitor, and has been turned into an application server, whereas JBoss was always meant to be, what it is.