Who is Using Tomcat or Jetty in Production? 488
"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."
Support? (Score:1, Insightful)
One thing execs don't like about "free" is, whose fault is it when it breaks? They need somebody to yell at, and don't ilke anything being their fault. So as long as you can get good support for when all hell breaks loose, you should have your ground covered.
Just make sure it's good hardware (Score:2, Insightful)
Tomcat (Score:4, Insightful)
If you're going to replace BEA though, consider looking at JBoss which is a true J2EE server unlike Tomcat which is just a servlet container. To replace a commercial product such as Weblogic, WebSphere or iPlanet, you want to look at JBoss for a complete J2EE/EJB solution.
Re:We don't get paid to do your job (Score:3, Insightful)
You obviously don't.
There are quite a few companies using Tomcat 4.0 or greater as a production JSP server and JBoss if they need EJB support.
However, there are faster web servers out there.
Resin and Jetty come to mind (use Google to find the Sites). Tomcat is a "reference" version of a JSP/Servlet Container. It is the first out of the gate... Others optimize stuff.
Tomcat 4.0 and above is scalable and clusterable, so you have the ability to do that, but so are several other open/source or less expensive Web Servers...
Check them out.
And idiots like the one above... If you can't be constructive.. Don't demonstrate your ignorance... just shut up.
Choosing Tomcat over others (Score:5, Insightful)
As for support that was never really and issue with us so I have no argument there. Now Tomcat has some flaws (most in the JSP compiler Jasper and their live redeploy area), but is otherwise a very sweet little servlet engine (don't call it an appserver it isn't one in the J2EE sense of the word and that is the game you're playing when you use things like servlets).
Once it has compiled your JSPs it works just fine and the sweet things and the selling argument for our projects was redundancy of providers. You have a change of enviroments like going to another servlet engine. With a very minimal amount of care in your coding and everything is portable in fact if you stick to the Servlet/JSP api then you're good to go.
In fact we had some time one evening and switched between Tomcat, Resin and Jetty with only a few minutes spent making the configurations fit and the files unpack and install.
On a sidenote if you can delay any lock-in on a specific version of Tomcat, try and see if you can get your system over on the upcoming Tomcat 4.1 I am loving the improvements it brings esspecially in speed.
You should try to change his opinion on jBoss though. jBoss has been the most loved thing about that recent projects (and EJB writing is in combination with a good Ant script and XDoclet http://xdoclet.sourceforge.net not that big a pain). It is probably the most stable thing about this entire project with hot redeploy (great for development), good performance and great ease of use and install on top. In fact the new 3.x version is even greater with clustering, failover and some very interesting innovations in the area of control over which parts of the server to actually run via SARs and JMX. But enough about all this.
Re:Tomcat is bad but alternatives are even worse (Score:2, Insightful)
-ax
listen to his boss words (Score:5, Insightful)
he doesnt want to know what he can gain by using either of them, he wants to know he wont lose anything.
Not exclusively but want to (Score:2, Insightful)
So I'd like to stand forward and say, yes we use Tomcat, and yes it's been in production so long we'd never consider Weblogic as a JSP/Servlet container.
Re:Tomcat is bad but alternatives are even worse (Score:3, Insightful)
So the majority of webserver admins in the world are having a bad dream ?
Look, trying to use logic and something arguable to express your views is OK. But when you claim that the majority is stupid without any backing for your claims. It realy looks the other way.
Lack of good benchmarks makes it tough to decide (Score:2, Insightful)
The problem seems to be that it is extremely difficult to benchmark such servers. Greg Wilkins [mailto], one of the primary authors of Jetty [mortbay.com], explains the issues fairly clearly in a response [yahoo.com] to the Jetty Benchmark thread [yahoo.com] on the jetty-discuss list [yahoo.com].
In addition, experience shows that J2EE application optimization is not as straight forward as other Java applications, so it is easy to get radically different performance results from a servlet with only minor tweaks. There was a wonderful presenation at JavaOne 2002 San Francisco about servlet optimization (link for atendees only [sun.com]). Among other things, the author demonstrated. a simple 6 line "Hello World" servlet that is written in standard style, yet can be made to run 3x faster with only minor tweaks. He also shows that testing under load reveals that servlets can behave much differently under load and that the only way to really write fast and reliable servlets is to write them as you normally would and then test them mercilessly.
My conclusion is that you can't believe any of those published bechmarks, they're mostly biased marketting crap (everybody's benchmark seems to show their product is fastest). What you really need to do is load up multiple servers and configure them to do what you need them to do and test them under load to see how they perform in your environment. I know it's not what you want to hear, but since there are so many features that have varying performance, it's the only way to really find out.
Re:Tomcat does suck, avoid it. (Score:5, Insightful)
You didn't mention what spec you mean but I think you meant that Tomcat implements Servlet, JSP etc. specs poorly?
I wonder what is your standard for poor but you can't get any better compliance than what you get with Tomcat namely it happens to be the official, Sub-blessed reference implementation of these very specs. If you're in doubt, then check these URLs: Java Servlet technology - Implementations ja Specifications at java.sun.com [sun.com] and Front page of Tomcat site [apache.org]. Thank you.
Re:Tomcat is bad but alternatives are even worse (Score:2, Insightful)
Re:My company uses tomcat exclusively (Score:2, Insightful)
And if you are not using Ant for builds, I would highly recommend you check it out. It's saves me so much time and, when I actually did have a job (a year ago), it saved my team and incredible amount of grief and time.
Apache is a configuration nightmare? LOL! (Score:1, Insightful)
Just a thought.
--Me
Re:JBoss ! (Score:2, Insightful)
Tomcat, Jetty, Resin, etc. are Servlet containers. They are designed to run web applciations built on top of servlets and JSP. They also integrate with Web servers such as Apache and IIS to optimize the serving of static or other (e.g. PHP) content.
JBoss, as well as IBM WebSphere, BEA WebLogic, Macromedia JRun, Orion, etc. are J2EE servers. They provide support for Enterprise Java Beans, as well as a lot of other technologies in J2EE, including Servlets and JSP. Some of the J2EE servers have their own internal implementation of a servlet container (e.g. Orion), while others use independent servlet containers. Comparing Tomcat to those is like comparing apples to fruits.
JBoss, in particular, comes in several different standard distribution, one of which integrates with Tomcat, and another that integrates with Jetty by default. I am sure it can be confugured to use other Servlet containers as well.
To address the main question, my personal experience is that Jetty is best for development because of its quick startup, although Tomcat is also fine as long as your development environment integrates with it well. In a production environment, I would recommend Resin and the Orion servlet container if performance is necessary. If it is not, Tomcat is okay, and the hot deploy feature in 4.x makes it a very attractive option. (I would just note that the hot deploy feature does not work in all cases, e.g. it does not work for Tapestry applications)
You need numbers... (Score:2, Insightful)
Figure out and document the "typical" type of application you will need to run on your app server, then design and document an application architecture for it. Once you have the architecture, create a prototype of the architecture that establishes a "thin thread" through the entire architecture. For example, JSP to Servlet to EJB to JDBC. This is really important because one app server may be super fast at parsing and displaying a JSP but horrible at authorization checking. Now that you have the prototype, the fun part starts.
Conduct scalability testing, load testing, stress testing, and fault tolerance testing on each app server you are considering. Use your prototype architecture for the tests. Collect all the numbers and graph them out. It's really important that you establish a baseline hardware configuration and maintain that baseline throughout the tests so that you compare apples to apples.
This process is time consuming but I believe it's a critical. You will learn boat loads about each of the app servers as you do this. You'll learn what it takes to set them up, configure an application for them, how to administer them, oh yeah and also how they perform for your architecture.
Re:Get away from Java (Score:1, Insightful)
You don't understand, Java was designed to let bozos write stupid code, and have it still run. You may be a good programmer, but there are a lot of stupid people sitting behind the keyboard that need the structured playpen of Java in order to be productive. That's why managers love Java sooo much - they can pay cheaper bozos who can't find other jobs to write their boring code for them.
Curl was about as close as you could dumb down lisp for the bozo programmer, and look at how sucessful it was - or wasn't.
Re:Is Tomcat crap? (Score:4, Insightful)
I can't help but think that this article is just poorly written. It doesn't really paint a clear picture of what he's using Tomcat for. He mentions nothing about the various configurations tested. It's way too easy to just write him off due to an overly evident bias against Tomcat from the beginning. (Hint: when attempting to persuade people, calling a benchmark test "Is Tomcat Crap?" reveals your bias...)
I use Tomcat at work as the development platform we use. We're probably going to be using Oracle Portal for the production system (not that I know what that is or what it uses for it's JSP engine, but...). It works fine for a development platform.
I haven't done any performance testing on it (yet), but when I get the chance, I might look into it. It'd be interesting to find out what my results are. I have a suspicision that Tomcat performed poorly in his "tests" because the other servlet engines came in an optimized for speed setting while Tomcat comes "optimized" for development.