Slashdot Mirror
Who is Using Tomcat or Jetty in Production?
"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."
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.
Berto
don't get too cheap on the Intel HW, I mean quality hardware - no software runs well when the tin memory contacts get flaky or the fans seize up after a week. Use a percentage of sw saving for quality stuff and rest is punching buttons with minimal finger pointing at the resident screwdriver jocky & board swapper.The last production box we got even for Msft 2K server was just a 1.1Ghz P3 w/ PC133 ram, and 2 40Gb SCSI disks (low voltage differential, new one on me). Giving untrusted hw a weeks thrashing under simulated production conditions builds confidence immensely and avoids em-bareass-ment.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
We've been using Tomcat in a production environment for 1 1/2 years and before that we were using Tomcat's predicessor JServ. It's been rock solid. 4.0 brought a lot of nice changes (like not overwriting the logs on startup!) and 4.1 is a refactoring release for performance. The one thing to keep in mind about Tomcat is that you have to write your own wrapper script/program to make Tomcat start up as a non-root user. If you're going to use it in conjunction with Apache, Apache2 will only work properly with the ajp13 connector. The webapp/warp connector doesn't seem to work properly yet.
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.
Some people take their .sig way too seriously
They don't put Anonymous Coward on the "byline" for nothing. A forum is designed to get information. The purpose of her post was to get some information from people who knew their head from a hole in another part of their anatomy.
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.
I come from a similar situation and have managed to do what you want to do. To sound a little zen don't try to change their minds just show them the benefits. In my case I drew on my knowledge on the lack of vendor lock-in combined with the economics of the situation and the inclusion of support in our seperate support contract (really cheap support at that).
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.
And just what web server do you prefer? There isnt a product out there that can touch the versatility, reliability and stability of apache.
-ax
to tune your answers.
he doesnt want to know what he can gain by using either of them, he wants to know he wont lose anything.
At NetDoktor A/S we use Tomcat/Weblogic currently to run our Java platform. We're deseperatly trying to gain time to look at JBoss to see if we can kill off Weblogic.
/Ian
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.
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.
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
The problem seems to be that it is extremely difficult to benchmark such servers. Greg Wilkins, one of the primary authors of Jetty, explains the issues fairly clearly in a response to the Jetty Benchmark thread on the jetty-discuss list.
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). 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.
Signatures are a waste of bandwi (buffering...)
What the hell are you talking about?
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 and Front page of Tomcat site. Thank you.
because using Tomcat to serve static html and images is like using a an suv to deliver 2x4 and drywall to your construction site. Sure, they fit in the vehicle, but its not exactly optimal, not by a long shot.
.sigless since 2003
This sounds like a pefect job for Ant. I am sure you can find a way to make Ant alter the config files then produce individual WAR files for each server.
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.
Just a thought.
--Me
I just want to clarify a couple of things that seem to confuse people a lot.
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)
Every application has different performance requirements and every app server has different pros and cons. It's absolutely critical that you figure out what you need from the app server.
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.
And exactly how much are you going to pay for a sharp lisp programmer, if you can find one?
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.
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.
You are in a maze of twisty little relative jumps, all alike.