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."
Can't give our company name but we're using it in production for an ASP-type senario serving apps to large financial institutions off of WinNT boxes. Compared to the previous IIS builds (ugh) it's wonderful, stable and a nice advert for taking the whole show over to UNIX.
Well how about I call your boss and take your job? I have been out of work for some time and I am REAL hungry. Where do you work again?
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.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
We use Tomcat in production, as a replacement for JRun, which we used to use. It's working quite nicely.
Novell's Groupwise version 6 runs on Tomcat with Apache. It's actually set up to run on Netware, of course, but I've gotten it running quite nicely on linux as well.
"Tell me doctor, with all of your defenses, are there any provisions for an attack by killer bees?"
'So I'm thinking, am I missing something by not using Tomcat? Do I have anything to lose?'"
The only thing you have to lose, due to the fact the Tomcat is open source, is real support for technicians. But real men don't call tech support, right? Anyways, Tomcat == BEA - tech support.
Take a look at JBoss, we replaced BEA with it for commercial product deploys and have been thrilled. It can also be integrated with Tomcat or Jetty.
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
It will run on Linux.
Tomcat 4.x series is designed and built for production use unlike the 3.x series which was a reference implementation donated by Sun.
Anyway if you're not doing EJB tomcat is a reasonable choice. If you ARE doing EJB work you can pick up JBoss which integrates well with Tomcat. Pick up GLUE for web services and a decent persistence layer (OJB for example) and you're all set for enterprise level development with $0 spent on infrastructure software.
Your pizza just the way you ought to have it.
We use a BEA app server at work for our order processing system. Generally it works ok, but serious bugs in it cause us a lot of greif and downtime. First off it has serious memory leaks in the performance pack (trading speed for stability). We have to boot the BEA app server at least once a week least it runs out of memory and crashes. We are currently looking at JBOSS as our new production application server due to it's stability. If you code smartly you can move the code back and forth so you really have nothing to loose....
Got Code?
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
Go not to the Elves for counsel, for they will say both no and yes
58k.com is the leading online print job auction company and they their entire operations on open source software.
Here is a case study.
~ fact is not dependant upon your belief therein. ~ ~ Have I therefore become your enemy because I tell you the truth?
"In conclusion, yes - in my book Tomcat is crap. I haven't actually really touched on the problems with Tomcat here (other than it has bad performance and bad developer productivity) and I apologise for that. Perhaps I'll get to them another day. For now, consider the other alternatives until Tomcat improves (which I hope - but doubt - it will)."
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.
JBoss is an excellent fullfledged J2EE application server.
:)
They even offer consultancy if you cannot get it right the first time.
Excellent award winning server, excellent support, what do you need more ?
It has Jetty integrated and gives you the full J2EE stack.
You can get it to work with Tomcat too: no problem.
Check it out, the design is awesome for the techies.
The support option is great for the management.
Everyone's happy
This guy must have made this scenario up. No one in their right mind would jump off a stable Sun setup just to use Java and Linux.
C'mon man, do your own homework and figure out what to do yourself. Resourcefulness is one thing, asking a public messageboard because you're lazy is another. Now quit posting messages and go and do some work...
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); }
hi,
I also working for a 'global financial institution' and we are using Jetty+JBoss in production now. We also have many tomcat/apache installation globally. I personally pefer Jetty over Tomcat for the performance.
Apache is nice and fast for serving up static pages, and really nice with php pages.
But in my own personal experience, and this was 2 years ago, Tomcat was really slow. It seemed to be just average with jsp pages, and then the more towards the j2ee route you went, the more worthless it was.
we were mainly using it as a quick and dirty testing/training server system, so I would assume that perhaps it has either come a long way since then, or it is only really meant to server jsp pages.
There are some odd things afoot now, in the Villa Straylight.
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.
We use tomcat in our company (a Fortune 500 to remain nameless) for all of our J2EE stuff. I hear Jetty is faster/more lightweight, but there are more books and other docs out there on Tomcat. If your company is looking to save money, why would they go to linux to save a little $$ on hardware then turn around and use BEA products to spend a lot of $$ on software? Makes no sense to me.
Don't know if I can give the name, but it is one of the largest pharmaceutical companies on the planet. Some BEA.
I'm leading a dev group that is stuck on a Java based App server (Silverstream) which we are not very happy with. As half my team would prefer to be linux based, we would like to migrate from windows to linux for development (hell, servers too).
We've been playing the "more stable/reliable", "more flexible", "more standard", and "less bugs" cards and I am actually seeing upper management start to sway. But I am still looking for some more fodder, anyone know of any good performance reviews or any reviews at all the put tomcat/apache against any app servers?
http://monkeyserver.com --- weeeeee
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.
running on Linux for all our clients. We build and deploy customized web apps for our growing client list. We have been running Tomcat for more than a year, and its performance has been superb. Of course, our clients don't have high volume web sites. And we're not a large company.
Guns don't kill people -- people kill people.
But the guns seem to help a bit. (apologies to Eddie Izzard)
Just be aware that Tomcat is not optimized for speed. Tomcat is optimized to implement the JSP spec.
What savings do you think you're getting on the Intel hardware over, say, the newer Sun kit such as the v480 and v880? The newer Sun boxes are more scalable, more powerful and have better support if needed and similar prices to the Intel kit.
Don't you need anything more than a few 1 or 2 cpu boxes, with no requirements for scaling in the future?
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.
If you end up using Tomcat, I would suggest you deploy it as part of JBoss, even if you don't use EJB. The reason is the enhancements to Tomcat delivered by the JBoss integration. These include hot-deploy for Tomcat, which Tomcat (afaik) doesn't give you on its own, JMX, clustering, security, connection pooling (maybe Tomcat does this ...), etc.
Also, as a further suggestion, ensure that you get information on Tomcat 4.x, as it is intended for production use. The 3.x versions were not.
Good luck!
--Kevin
We use Tomcat pretty extensively over here (major league northeastern university). I have heard that Jetty and Resin are much faster. I have also heard TONS of praise for Resin (faster, easier to configure, deploy, etc.), so you might want to look into that.
That said, Tomcat is perfectly adequate. Unless you are running Ebay or Amazon.com or something, your main bottleneck will probably be your database IO. Typically Tomcat (and any servlet engine, in general) is set up with mod_jk hooked into Apache, so that Apache is the frontend that serves all static files, and *only* those paths which are servlet/jsp get forwarded to Tomcat. In the recent past there seems to have been some flakiness in the Apache->Tomcat connector, but I presume that has been solved by now. Also, until 4.x, the configuration file format, and class loading mechanism were changing each release, but I believe that has settled down.
Like many Apache (or maybe Open Source in general) projects you pay for not having the depth of features a commercial product would, but you get in return breadth of features, and the comfort of a de facto standard with tons of inertia and support behind it. Besides, the J2EE specs are written sufficiently well, that any servlet engine implementation is basically a dime a dozen. You won't lose with going with Tomcat - and you can always switch to a commercial product if/when you feel you need richer/deeper features (I know people who develop on Tomcat, but deploy on Resin).
I must still be naive because I still can't fathom the absolute craptacular $$$,000 amount companies spend on commodity software. Unless there is something you *really* need in a commercial product, it is usually not worth the hassle chaining yourself in.
It's 10 PM. Do you know if you're un-American?
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.
After IBM started charging for WebSphere on AS/400 (I think it was after V5 was released) we switched all our development to Apache/tomcat, and strangely, this is what IBM recommends. IBM ships apache and tomcat with OS/400 and it works like a charm.
We just deployed a servlet/jsp application on the AS/400 last week and we're just about finishing another major application for deployment next month.
Performance-wise we've seen very little difference between WebSphere and tomcat, at least on iSeries, though I can't really speak for other platforms.
cheers
Dont run all your applications on tomcat. I understand the cost savings, but there's something to be said for prudency.
.. test applications running on it versus tomcat. Tomcat will be noticably slower and unscalable for large apps. If your test results are inconclusive as to whether it meets your needs,
.. have websphere or weblogic deal with peak times at first ... and then have tomcat slowlyt move in on pealk times until you're websphere and weblogic free.
Nobody got fired for going with IBM.
Get a 30 or 60 day Weblogic/Websphere demo
dish out the cash for BEA or Websphere, and have some of your apps running on it (JSP is portable so it wont be a biug deal). Then as time goes migrate everyuthing over to tomcat.
That way you know it can handle the load.
You can also find out what your peak times are
Oh, anpther thing you can tell your boss is that you can easily move your apps from tomcat to weblogic anyway. and since tomcat is free, ypou wouldnt have wasted money when you switch to higher ebnd software.
I find that our Tomcat does an excellent job of keeping the programmers in line.
UK local authorites, via the Accessible and Personalised Local Authority Websites.
This is a web toolkit based on the Arsdigita (of Phil Greenspun fame) Community system.
Their setup is *nix, Apache, Tomcat/Resin and Oracle.
Live today. Tomorrow will cost a lot more!
Is Tomcat the best for java servlets? My company is considering tomcat for windows, however the developers are having trouble increasing the virtual memory in tomcat does anyone know or can point me in the right direction?
Have you compared Jboss to Tomcat yet? Or are you still in the evaluation process?
Don't Tread on OpenSource
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 is okay, but I personally prefer Orion, 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.
Everybody dies.
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.
Compared to Orion and Resin, Tomcat also lost comprehensively. The arguments raged for a while over performance (for example)- 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.
I just installed the Jetty Web Server the other day so I don't have any real data to provide, sorry. I know of a few people that use it and have been happy with it. The only complaint that I've heard is that the pages take long to load. The person that said this thought it might have to do with the page being Java, but I think it might just be the database itself causing the slowdown. Just my $.02 worth.
We have migrated to Linux, Apache, and Tomcat over the last year-and-a-half. We use it both in development and in production, across 100 or so boxes. As with everything, there are issues, but for the most part we are very happy. Even most commercial vendor's idea of a "big" site doesn't come close to what we do, so we have found very little difference between problem solving in the open-source and closed-source worlds.
For what we do, you can't beat the price... And yes, that includes the price of our time.
I used resin a while back and it worked great. These days, I'm back in the world of perl, so I don't know what's current. Also, we didn't have high load. Can someone please inform us as to whether or not you need risc processors to really get the most out of Java.
I get the idea that the best java virtual machines are made for sparc and the other big risc processors. ia-32 doesn't have a really well optimized jvm. Am I right or wrong?
...richie - It is a good day to code.
My former employer, a very large areospace company, was at one time very very much against any software that wasn't back by a "stable corporation".
... just in case it doesn't work out. Perform a cost/benefit analysis. Purchase a product if it's the right decision - don't let "free" blind you. Write white papers for management. Counter industry FUD "reports" ... as they're often BS that are easily attacked.
The excuse was that if something went wrong, my company could sue the pants off the software provider. Of course, they almost never did that - instead, they just wouldn't pay the bills until the provider complied with company demands.
Enter terminal emulator software. The popular 3270 emulator cost about $500+ per desktop. And with 10,000's of desktops, that was... um, expensive. So I started my own little cost/benefit analysis. We could buy a shareware product for $5 per seat, and it was very robust and served 99+% of the users (except for mainframe sysadmins, of course!).
And the savings was amazing. We rolled out the product slowly. Everyone was happy. In the end, everyone used the product.
This one little step put us on the road towards purchasing more shareware. Soon afterwards, we did the same kind of argument with freeware - and won.
Conclusion: Start with something simple that you can back away from
faster, more stable, easy to use and to install.
As with many other people on this list, we are using Tomcat exclusively, development, staging and production, for all our new projects.
We have a virtual press office tool that allows zip files of images to be uploaded and re-scaled to several sizes, using ImageMagick & JMagick, and we only have speed problems due to browser upload timeouts when our users upload huge zip files.
-- I like the cut of your thinking, young man. - me.
We began using Apache-Tomcat to replace SilverStream as our app server for awhile now. It works better, faster, and best of all... CHEAPER. At first, our developers were hesitant to switch but now they absolutely love it. Unfortunately, the Apache-Tomcat combo is the only thing stable that our dev guys do... one day they will write decent code.
I don't drink because I have to, I drink to stop the voices in my head!
We're running Jetty on an AS/400 in production. Startup times are slow, and I think we'd get much better preformance using a native language on this platform, but it works pretty well. It gets the job done.
© 2004 The SCO Group, Inc. All Rights Reserved.
Tomcat 4.0.x is the latest and greatest. From what I can tell and have read on the various mailing lists, it is a significant performance improvement over the older Tomcat 3.x line. Heck, even the Jetty folks acknowledge that Tomcat 4 is almost as fast a Jetty ;)
Signatures are a waste of bandwi (buffering...)
The first thing I noticed was the speed. Once compiled, servlets and JSPs ran noticeably faster than their mod_perl counterparts, on the same hardware. In addition, the structured development environment and cleanliness of Java (with respect to Perl) seriously streamlines the construction and rollout of apps.
The only thing I miss is CPAN. Perl has a vast archive of ready-made code libraries that do everything one could imagine. With Java, I was severely limited -- even having to roll-my-own UNIX-compatible MD5 password routines. However, given the improvement in overall development, I wouldn't switch back.
BEA's a good server, if slow, once you get around the absolutely awesomely bad management tools they tout as being so good. (Hint: they're not. If they work for you, great. We've found that we end up deploying the same applications multiple times, with restarts, in order to get the thing working correctly; this is with BEA support riding alongside to make sure we're not doing something stupid. We weren't.
WebSphere... IBM, IBM, IBM. The best compliment I've ever heard about Websphere was from a fan, a developer who loved it: "It's not that bad..." (Yes, it is. In IBM's sales meetings, they crow about how they helped design the entity aspects now-hopelessly-muddled EJB spec... and then later in the meetings they denounce using entity beans altogether because WAS can't give you any good performance with them. Plus, being tied to WSAD isn't my idea of a good time.)
JBoss is really pretty nice - it's built entirely around a component architecture, so you can swap out the Tomcat crap if you need to and replace it with something that actually works. (The default servlet container that comes with JBoss is Jetty, which you should replace with the current version of jetty if you use JBoss. The Jetty that ships with JBoss has a jasper error, jasper being a component from Tomcat.) The only issues I have with JBoss are related to its strengths: the component architecture means that each component chooses how it's administered, so you end up not only learning how to handle JBoss itself, but you have to learn how to configure Jetty, or this product, or THIS product, or THIS OTHER product... I prefer one ring to rule them all, etc.
As far as performance reviews, use google! :) I've done some informal performance reviews, and I've found the two best performers were Resin and Orion, with Resin being a few milliseconds behind Orion in terms of servlet and JSP performance.
Everybody dies.
the big question begging moving from a simple jsp/servlet engine like Tomcat/Jetty/Resin to a full blown J2EE app server like WebSphere/BEA/JBoss is Do you want to run EJBs?
... Tomcat is used by IBM WebSphere to run all the jsp and servlets in webSphere, which in turn can then utilize the EJBs...
i'm not an expert on EJBs by any means, and i'm trying to ask this same question of my own projects, but what i keep hearing is this: EJBs allow me to run much more scalable than servlet/javabeans.
i dont know what your prospective usage numbers are, but if they are large scale (aka site on the internet that loads of people will hit hard) then you want to use an EJB architecture because you will be able to scale up with lots of big servers. given that you are working on PCs, my guess is that this is not the case.
Also, i keep hearing that utilizing an EJB App Server will bring with it database connection architectures like Container Managed Persistance etc. BUT... there are some great examples of utilizing other data access patterns like Data Access Objects (see the jpetstore example)
i think it comes down to proper application architecture. make sure your applications have good design, and keep in mind scalability (especially with the data access bottleneck) and you should be ok.
oh yeah... in favor of tomcat
"Who is Using Tomcat or Jetty in Production?"
The same people that uses MySQL in production.
Oh, and Resin is about 4x faster than Tomcat. See here
fanny. It's a different word in the united kingdom.
We're using Tomcat on servers here to replace PHP on Apache. Eventually we're going to phase out Apache and use just Tomcat. It works great except for one tiny thing for us, there's no equivelant to htaccess. Which makes setting up restricted parts of our website a tiny bit annoying. But once you get the hang of the xml config files it's pretty easy. As for robustness, one of the sites we run it on gets a few hundred thousand hits to the same 3 or 4 webapps. I think it's great. But I can't give out the company name.
Kintanon
Check out JoshJitsu.info for Brazilian Ji
I've got no experience with Resin and not too much with Tomcat. (I've used JRun and Websphere in the past and I like them both.) Anyways, there is a company at my local Java Users group that really speaks highly of Resin - I think this is the link.
Obviously it's not open source which isn't exactly what you're looking for. On the other hand, what I hear is that it is fast, stable, and inexpensive. ($500 per deployed server.)
We use tomcat in an ASP hosting 30 clients, as well as ship it with our software license. All told we have over 50 clients using tomcat, each with user bases in the 100k's. Tomcat has been very stable, reliable, and efficient. However don't ever hope to understand anything from the docs: "fixme" is printed more than periods. The tomcat-users mailing list is an excellent resource when the docs fail you.
Help, I'm being repressed!
I honestly don't get why people are so hung up on Java on the server. This isn't intended as a flamebait, but mod_perl is a very fast, very stable and very powerful solution. There are tons of modules out there already on CPAN, and the stuff just ... works. True, you can write really bad code using Perl. Java tends to force you to do things a certain way, whereas Perl is more tolerant. But, if you know what you're doing, and know how to architect large systems, you can definitely write large systems using mod_perl. But everywhere I look these days people seem to mindlessly keep chanting "Java, Java, Java", particularly with relation to "enterprise". I know for a fact that there's nothing in the "enterprise" that is the sole domain of Java. It's just another language, but very successfully pushed by Sun. Sure, it works, and has a right to exist, and it'll get better. But I'm a little irritated that existing solutions such as mod_perl are relegated to the dustpile in many people's minds simply because of an outdated association with the slow cgi stuff.
Ok, you can mod me down now for "offtopic". Just thought I'd try to add another perspective...
My company uses it (can't reveal name here - contact arozeluk at websoup period net directly and I can tell you)
We replaced our application, an ASP/COM deal that was horribly unstable, with two load-balanced front-end servers running RedHat Linux 7.2/Apache/Tomcat. This setup's been in place since last December.
Originally we started on Tomcat 3.2, then upgraded to 3.3. I'm in the middle of fixing up small things to make everything work correctly with Tomcat 4 (no major problems, just trying to take advantage of new features). But our production is still Tomcat 3.3 for the moment and it's been great!
If you can, go with Tomcat 4 right away. While I've found both to be stable, Tomcat 4 seems to be faster and also has built-in support for JNDI database connection pooling. Big plus.
Don't trust servlet reloading, though. I've had problems with it. Thus, no updates are made to our application during the day, which normally isn't a big deal. A quick FTP of new code at 2am, and a restart-by-crontab and the new code is loaded nightly.
Tomcat 4 also attempts to preserve sessions between restarts. This is neat, but in a load-balanced configuration won't work because the user will be transferred to another server, so their session would be lost. It takes quite long to shut down and restart Tomcat 4, but in my environment it hasn't mattered any.
I say go with it. It's been very stable for us, and if you email me I can give you further details about exactly what our app does.
Note that there's pages out there which describe how it might be possible to replicate sessions between servers. I suggest you investigate this before starting. Until now I haven't had the time, but I will be looking into it shortly as it would solve the problem of needing to restart the application during the day for me.
You can accomplish anything you set your mind to. The impossible just takes a little longer.
Sears uses them with wireless scanners for inventory control.
"Going to war without France is like going deer hunting without your accordion." - Jed Babbin
Resin is the fastest server I know of. It's only $500, and the source is available. And capable of handling high loads.
Orion is nice, but not as fast as resin, and is $1000.
I think resin is the best choice. It's blazing fast and only 500 bucks. Start up in a second, and does have the dreaded classcastexception..
Also for development it's by far the best because you don't need to restart it when you change classes (orion and others throw the classcastexception, they have some classloader quirks).
I use resin in production and development.
Their position is that it will save them hardware costs to run on Intel machines instead of big IBM or Sun iron.
:-)
You mean AMD Athlon MP machines, right?
My company (a financial institution using tomcat 3 on AIX servers) is still using older versions of tomcat to serve up our jsp's. The main reason we use an older version is simple: tomcat can be a bitch to configure We've had tomcat 3 working for about two years, give or take, and migrating from 3 to 4 could be a potential nightmare (there are some groups who have already tried it inside the company and spent many a weekend in the office scratching their heads). While I will agree that tomcat is slower than Apache, there are tweaks that you can do to prevent the webserver from crashing and to speed things up a little bit. One such tweak is increasing the default memory allocation from whatever it is set at (i think 64MB) to 256MB(or whatever you see fit). Granted there are problems in doing this, too, but it does speed speed things up in most instances. Just make sure you have your stressball handy next time a nullPointerException rears its ugly head... :)
"How it infuriates a bigot, when he is forced to drag out his dark convictions"-- Logan Pearsall Smith
I've deployed a complete production setup using apache with mod_ssl as front-end and using apache 4.x in the backend with PostgreSQL 7.2.x all under linux.
first off, our production server software costs were 0. this is nice.
some folks may say apache, or tomcat or postgresql is slow. well, the vast swathes of cash you save on server licenses you can stick into decent hardware. in this case, our boxes are quad processor machines. slow? no, they are not. rock solid, very fast and easy to maintain.
so basically, if stuff runs slow then use a faster machine. works out cheaper. besides, i like tomcat a lot.
Compiles on the fly, the help is in english (unlike tomcat). There are usefull forums with people who have the same issues that you may have, installs easy as a services, compiles on the fly, easy to configure (once again thanks to the help).
I personally think that Tomcat is one of the reasons why the Open Source movement gets a bad rap. Yeah it's free but what good would a free airplane do me if I had to fly it myself but could not learn how to fly?
The support sucks! might as well have the help written in Russian. If you are not an advanced user you will not get it working easily.
No one wants to bother with spending hours setting the app up, people want to to code and put up the web sites ASAP.
I've heard good things that the Navy has been using Tomcats in production use for quite a while now. They even made a movie about it.
I work for Watchfire a leading maker of website quality management software. One part of the suite is FeedbackXM, a user feedback survey system (of the survey button on the web page / pop-up survey kind.)
FeedbackXM uses Tomcat as an application server. This information is in the customer documentation.
http://trafac.chmcc.org
It is a bioinformatics web site for finding promoters in DNA sequences.
I did not design it, I work on it though (use and develop it).
Won't put our company name on here(it is a large UK health insurance company), but we use apache and tomcat for all our large scale web apps. For example we saved huge amounts of money by fronting our legacy middleware product with an app that you call using XMLRPC and it sits on Apache and tomcat on a Sun E10k domain. For performance it handles about 30 requests per second and about 1.2 million calls a day.
:)
The reason for this combo? It works, we tried other products and they couldn't handle the load, and when you dig deep then the parts we were using were old versions of Apache and jserv or tomcat!
"Because we are not employing at entry level, offshoring will kill our industry stone dead."
I've deployed Tomcat 4 in a fairly large corporate intranet and had relatively few problems with it. The main issues I encountered were its flakiness in integrating with the Apache http server. My goal was to use Apache for serving up the static html pages and then using the mod_webapp connector to forward jsp requests to Tomcat. This was frustrating in that the documentation for doing this is very scarce and I also encountered some stability issues. What I ended up doing was bypassing Apache altogether and serving up everything using Tomcat (99% of the pages were JSP anyways).
Hopefully they've resolved some of these issues since the 4.0 release.
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.
(Anonymous because I'm not entirely sure what of this is appropriate to disclose from the company I work for)
Tomcat isn't even remotely production worthy. Performance is absolutely horrid, to the point where we rarely even use it for development (although personally, I do...).
We've found that JBoss/Jetty running a very large enterprise application (gig+ of ram usage, page rates in excess of 100/sec, nearly 40 meg of compiled java code) holds its own with all the other expensive app servers we've tested (WebLogic, WebSphere, etc)... Most of our customers use WebLogic, because they are Fortune 100 type companies that already have site licenses, but all of our internal ASP hosting, all our pilot and demo systems, and 90% of our developers run on JBoss/Jetty.
haha, we use it in production but had to write a little script to restart it every 300 connections or so cause we had problems with it clearing out old/unused connections... have fun!
Actually, it's not just per server -- it's per cpu which can get expensive in a hurry if your loadballancing accross a couple 4-cpu sun boxes.
I would have no hesitation in recommending Tomcat for low and medium traffic sites; I don't really know enough to recommend it for very high traffic sites.
I'm old enough to remember when discussions on Slashdot were well informed.
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
Soccer Goal Plans
We are using JBoss and Tomcat in a production system, deployed in the government offices of 9 different governments.
For more information, see www.trackernet.org
Documentum, a very large purveyor of high-end content management software, says they will begin shipping Tomcat with their v.5 products in November. They are converting from a proprietary macro language and preprocessor to JSP for all of their web interface functions. Customers who already run either ASP or an app server like BEA or WebSphere won't have to use Tomcat.
IMHO, that's a pretty significant endorsement. Unfortunaely, all the v.5 and Tomcat info is in their developer site which requires registration with a prodcut key.
Sun's new Sun ONE application server has a free Liux version (I think it's in beta, but you can ask Sun for a copy). Although TomCat is a good implementation, Jboss is way faster. If you want support, go for the free Sun ONE application server.
Here are some good reasons to use Resin:
- Fast, reliable, scalable
- Easy configuration
- Full source code provided under a "Developer Source" license, which makes it competitive with "free" products, at least from a commercial perspective
- Development use is free - no licences need to be purchased for development and testing purposes. Runs well on Linux as well as Windows; latter can be useful for test deployments on developer machines
- Inexpensive to deploy: $500 per server for the JSP version, $1000 for the EJB version; additional for priority support options.
- Commercial support - see their pricing page.
Here's a testimonials and customer list which includes some pretty big names.Despite any appearances above, I'm not associated with Resin, except as a customer. I first heard about it here on Slashdot, a couple of years ago. We evaluated it and eventually switched a number of applications from both Tomcat and commercial servers and have never looked back.
Other servers that might be worth looking into are Orion and JBoss, but I don't know how they compare on some of the points above. The availability of commercial support from the vendor can be a clincher, and the source code provides some insurance against the vendor disappearing.
I agree with all the cautionary comments about Tomcat, although we haven't worked with it for some time now.
Cisco is working towards moving all their web based applications to tomcat. Just about all their new applications are being written there.
Tomcat works for us. Regarding speed, if everybody says it's slow then maybe they're right. However, in my experience it's the database interaction that's slow, not the java code. Tuning the query can cut seconds, tuning the java cuts milliseconds. It's hard to fuss too much about the milliseconds when there is low hanging optimization fruit to be found in the sql.
Vanguard
That which does not kill me only makes me whinier
I 'm using Tomcat for an old JSP-Application. It is rock solid. For new Web-Application-Development, the ZOPE-Framework is much easier to handle.
I manage a few servers...
1 Apache box on an Ultra 5 (Slow sun box typically used as a workstation)
1 Tomcat box on an Ultra 5
I use mod_jk and hide the tomcat box behind the web server. This adds a nice layer of security and lets Apache process
In total I have 5 instances of Apache, ~100 instances of tomcat, and ~150 web sites. The apache box sustains about 2MB/s and about 400k/s gets sent to the Tomcat box to deal with. I have had very few problems with Tomcat 3.3.
If you need some redundancy I would recommend using the mod_jk load balancing. It works very well and is simple to setup.
My advice: Don't litsten to all the Slashdoters who gripe about anything to do with Java, give Tomcat a try. It works for me!
BTW: If you want to get into J2EE stuff, absolutly use JBoss!!! It rocks!
Wow, the posts so far really bear out your point -- a lot of long-winded opinions but in 115 posts, only one mention of actual production traffic.
.jsp's that talk sockets to the back-end (no database -- use Slashdot for your example there).
Go for it. I have been running tomcat in production on a public site for 2 years. Currently it's getting half a million hits a day and purring along at 3% CPU usage per Xeon. Over half of these are dynamic
Tomcat 3.3 was an improvement over the last 3.2 update. Haven't tried 4.0 in production yet.
BEA has no clothes!
We are also using BEA weblogic, and we would like to move to Tomcat or JBoss, However we also use Tuxedo.
What opensource alternatives are there for Tuxedo?
That should help, although I think they bundle Tomcat-Apache with Apache only. However the web server is apache in my understanding?!?!
I could be wrong however (as my wife frequently points out! lol).
I've seen a couple mentions of it, but here's a full fledged endorsement. If you hang out in #java in efnet, they pretty much unanimously recommend Orion or Resin, with the majority going to Orion. I've been using it for 6 months now.
It's ridiculously easy to set up (moreso than Resin)
it's fast, faster than weblogic/tomcat/resin
it's stable (I've had it running it (http://www.squabble.org) for that 6 months execpt when I moved it's server a couple months ago)
it's cheap. It's not free (as in beer or as in source) but it's a heckuva lot cheaper than Weblogic, and the development licenses are free.
for those of you who don't like Tomcat's start up times, it takes all of about 5 seconds to launch and you can redeploy a webapp simply by touching it's web.xml
Anyway, it's a great app. Give it a look.
Tomcat is good as a JSP engine, it will not replace what BEA does for you.. If you want to replace weblogic with open source, look at JBoss which uses tomcat as a JSP engine.
Wow talk about timing,
Right now I'm in an IBM lab doing performance measurements of a webapp I've written, hosted by tomcat 3.3.1. Tomcat is running on 2 p660 6way systems with about 8 gigs of ram. Run AIX. This has been my experience so far.
Basic JSP responses are quite good. (Simple JSP page response times are about 4 - 15ms, with the more complex servlets taking about 100ms.)
The tomcat threading is very, very nice. All of the processors have even load.
Also Tomcat is so easy to install! On any platform. (I've installed on Windows, Linux and AIX. All are a easy.) Set JAVA_HOME and TOMCAT_HOME and your done.
In short tomcat is production quality. I wouldn't hesitate to use it.
with "servlet container" and-or "JSP container". both tomcat and jetty are fine examples of servlet and JSP containers.
an app server, i.e., a server which serves up J2EE applications, is more generally thought of as a combined servlet, JSP, and EJB container. BEA, IBM WebSphere, etc, and JBoss are the real players in this space, but Oracle has their own app server rolling along now too. FYI, JBoss ships both a Jetty and Tomcat distribution.
Tomcat is the reference implementation for the Servlet and JSP container APIs. This means it is absolutely the standard. While Jetty is great for being "lighter" weight and more easily embedded, Tomcat would have to be my choice for "open source" servlet and JSP container.
MORTAR COMBAT!
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...)
Eventually, I found out about Jetty. One of the major advantages of it is the deploy setup is very nice (drop the .war or .ear file into a directory and it works) and the integeration of the EJB container with the webserver (no RMI). We've had very good uptime (months) with Jetty and very few memory-style leaks. Now, I'm sure Tomcat has a good deploy, but I could never get it to work. Also, Jetty has a nice interface for handlers, to handle SSO (single-signon) before displaying the page, which makes it worth it.
So, my vote it Jetty (and Postgres and Xdoclet and Emacs, but that's beside the point).
--- My novel, The Mummy's Girl is now for sa
One company I used to work for, Saepio, uses Tomcat exclusively for production. Haven't had any performance problems. After some Java code tweaking, they actually got the performance better than mod_perl for parts of the application.
http://www.saepio.com/
Can't give their name at this stage, we're only small anyway but prior to me arriving they were using JRun 3.1 exclusively for our Java web app that is purely servlet based. I was studying Java at the time so I pulled down Tomcat, did a bit of configuring, packaged our app to the J2EE standard, deployed it and voila. From my experience performance with Tomcat 4.02 is on a par or even slightly better than JRun 3.1 on Win32 based platforms. We are now supporting both Tomcat 4.02 and JRun 4 for production implementations, as we are selling a product we find some clients like to have a commercial product for the application server. I've also had a bit of a play with Tomcat 4.1 and hold onto your hat as that baby flies along, can't wait until that is released (my company won't tocuh it until it's released). As far as the support argument goes, when it comes to the crunch who is it that ends up solving problems? From my experience my company doesn't even goto Macromedia, yet that is some of the opponent's first argument "yeah but who is going to support it?", so I'm the first to stick up my hand and say I will just to placate them, if they have someone to count on (ie. blame) they are happy. We have found a few clients that actually embrace open source and are already using various open source products in production, which is quite nice to see to say the least. :)
JaseOne
In the drops - An Aussie's musings on all things cycling
But just last week at our local Java users group James Duncan Davidson, the original developer of Tomcat (and Ant), and he really didn't recommend using Tomcat by itself in a large enterprise type setting where speed is an issue. He said using Apache to help serve up static pages/images will certainly help but it is important to keep in mind that Tomcat wasn't built for speed, it was built to be a reference platform.
On a side note Davidson is a good speaker and worth seeing if you get a chance to.
Hey boss, I think we should use Lisp for our new application...
Why don't you just use Forth?
It's for a relatively small internal server, a few hundred users who, more often than not, will never use it - just a few people now and again.
Works fine, though. We're happy with it.
Stupid sexy Flanders.
We may have been on a conference call a few weeks ago. Call it a hunch.
Here is my take...
I suspect you did a big cost analysis of the different Application servers out there. Looked at IBM, BEA, and a few of the other smaller players. Tomcat was listed, but written off. Things moving at the speed of business - the developers started building with Tomcat. Now there is lots of code and tweaking to Tomcat that may (may not) prove difficult to migrate. Additionally, it looks like your not going to worry about an EJB container for the first couple phases and focus on STRUTS instead.
Tomcat works great for development. It works amazingly well for fewer than 100 concurrent users - and that really works out to a lot of people. The cost factor is less of an issue. The full blown EJB container / CORBA ORB / kitchen sink tend to cost a pretty penny.... but a strait JSP / Servlet container do not. Weblogic Express goes for a couple grand - and contrary to what folks my say, you can get decent support from them. (Just make sure you are the contact rather than someone on the "business" side). I guess I view the cost as irrelevant at that point. Take the time to benchmark and load test on a production box (sparc?) a couple different solutions. . Some of the commercial Servlet engines are very fast - at the expense of some bleeding edge features you may get with Tomcat. Figure out if runtime or development time is more important.
That being said, yes... there are folks using Tomcat in production. I have seen tons of departmental stuff out there. Enterprise gets a little rougher - I've seen a few companies wedge it in.
+++ UGUCAUCGUAUUUCU
My former employer, a very large areospace company, was at one time very very much against any software that wasn't back by a "stable corporation".
The excuse was that if something went wrong, my company could sue the pants off the software provider. Of course, they almost never did that - instead, they just wouldn't pay the bills until the provider complied with company demands.
I hear this a lot but has anyone ever actually sued a software provider?
First, let's get it out of the way... you don't have to use EJB's to get the job done.
:-) )
EJB's provide a "less code" solution towards writing business logic. That comes in four areas. First, they provide cached resources (like connections to a DB, or access to a message service). Second, they provide transaction support. Ever try to keep track of a transaction while in code and find you actually have two commits, not one? Third, they provide failover and lateral scaling abilities (more small machines equals better up time). Finally, they provide consistent run-time controls that allow the developer to distance themselves from the deployment platform.
Can you do all of this yourself? You betcha. And if you want to prove how cool an engineer you are by writing it all yourself, by all means go ahead. If, however, you are on a deadline (like the rest of us) these things help. (And I personally like going home on weekends.
We use Tomcat on Solaris in a large production environment (10,000,000 hits daily). We use Solaris over Linux or BSD because it isn't any cheaper to run the Opensource options (consider v100 servers in a load-balanced server farm), and you get the benefit of a more robust OS. We also have a cluster which runs weblogic, and to be honest tomcat has a LONG ways to go to be comparable to some of the features of weblogic (such as session mirroring), but I believe it'll get there some day.
tora
Anyone running Vignette's V/6 Enterprise Application Platform is running Jakarta Tomcat. It's a prerequisite. You can of course make custom connections to another servlet engine, but it isn't supported.
I don't have a customer list or anything, but there it is.
The Dopester
"Yes, I'm a Karma Whore, but I'm doing it to pay my way through school."
Resin is significantly faster than tomcat. Catalina (Tomcat 4.x) has close the gap somewhat but if they still have a long way to go. OTOH, if cheap / stable is all you need then Catalina is a great way to go. FYI, Resin comes with all the source but is not free. Any of the EJB server will be total overkill and the overhead will soak you. And Websphere (at least the servlet side) is based on Tomcat (as is JBoss).
I am not a number! I am a man! And don't you
The servlet engine used in JBoss is Tomcat. Since he said he didn't need to do EJB (Servlets / JSP only) there is no value in using Tomcat with an EJB server added. That having been said, if I had to actually use EJB for something (shudder) I would use JBoss.
I am not a number! I am a man! And don't you
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.
Don't count on any BEA Weblogic outages to be any faster than this, though. In my experience at my company (Weblogic in production, Tomcat in development), Weblogic can take 5 minutes to shutdown and startup. It all depends on the number and complexity of your web application(s).
There are also manager apps for Tomcat, (at least bundled with Tomcat version 4 and up) to re-deploy content without restarting, that are nearly instantaneous.
Do keep in mind that Tomcat can't deal with EJB's, and so you'll need JBoss oran instance of Weblogic somewhere to handle those. But if you're just serving up plain JSPs, go for it. Tomcat is beautiful in its simplicity!
Maybe he's a bit rude, but I've never thought that Apache's configuration was a nightmare. Especially compared with another major free offering, which is configured with GUI boxes...
Tomcat 4 is still in the 4.0.x stage, so I think sticking with Tomcat 3 is a more reasonable decision. However, according to a benchmark my company recently did, Tomcat 3's perfomance sucks compared to WebLogic.
Basically WebSphere is Tomcat with a bunch of extra stuff added on. We do a lot of Websphere stuff here and if you are just doing JSP then Tomcat should be just fine.
There seems to be a real problem with techies choosing performance over conformance. I'll admit that tomcat is not the quickest. But it's cheaper, conforms better to standards and you will have no problem getting community support for it.
Marginal performance benchmarks on app servers are rarely the biggest issue. The thing slows down more because of bad application code than implementation of the container.
BEA may go 10% faster (probably 10% slower anyway), but that's not the main issue.
Think sustainable standard interfaces (conformance) it'll save you money in the long run.
My company has thousands of stores all over the U.S., each of which has a small AS400. WebSphere 2.0 runs on this hardware (slowly) but later versions of WebSphere have too large a footprint. 2.0 will not be supported indefinitely, and it has poor support for JSPs among other things.
AS400s are proprietary as hell and the cost of upgrading the memory in thousands of them is not something to take lightly.
We tried running JRun and other products on an NT box and just using the AS400 as a database server. This works fine until you start running batch jobs on the AS400. At that point your servlets just get ignored. The problem seems to be that if the AS400 is running at full capacity then it ignores any requests coming from outside it. An AS400 with sufficient memory works fine as a database server, but again we didn't want to buy the memory.
IBM's officially blessed solution involves running Tomcat on the AS400. We have found that it has a smaller footprint than even WebSphere 2.0, decent support for JSPs, and performance actually improves. We plan to roll out Tomcat chainwide.
I'd be surprised if your boss wasn't willing to do some tests of various application servers to see which work and perform the best.
At my old company Unanet we supported tomcat right along with JRun...as for development, I preferred tomcat. But customers could use either if they so chose. JRun was just a pain in the ass...
Pretty sure they still support it, but I wouldn't know anymore.
One high volume server product that seems to use Tomcat (3.3) is Computer Associates' CleverPath portal product. At least one instance its in use is at http://www.ves.ws. Custom application development currently being done within the VES system (which is an education portal for the state of Massachusetts) is done with Tomcat (over iPlanet: the administration and performance were much better), and there are currently 3 applications hosted within the portal running on Tomcat.
One comment: Tomcat without Apache (in my observation) is VERY resource intensive: my memory usage was greatly improved by front-ending with Apache 1.3.26.
There seems to be a lot of confusion about what Tomcat, Jetty, JBoss and J2ee App-Servers. They are not really competative but complementary products. A Java AppServer is composed of [at least] three main components. The HTTP deamon, a Servlet/JSP container and a EJB Container.
Jetty is a primarily HTTP deamon, it is designed to handle HTTP request in a scalable manner.
Tomcat is a Servlet/JSP container, it implements the Servlet API it provides limited HTTP handling and no EJB support. Tomcat is highly reliable more so than most commercial 'industrial strength' App Servers. On the performance side; the Tomcat 3.x architecture is not hot but is adequate for many applications, all but the heaviest loads. Tomcat 4.x is significant better in this regard, because it includes an enhanced HTTP deamon.
JBoss is an EJB container which uses Tomcat 4.0 as it's HTTP deamon and Servlet container.
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!
Why use BEA over Tomcat? The performance of Tomcat is pitiful.
Rather than pay $35K per server, though, you could go with one of the low-cost Java application servers like Allaire/Macromedia JRun. It's under $1k per CPU and it's more than twice as fast as Tomcat, rivaling BEA in features and stability.
Works easily. We have been using first Tomcat/JBoss, now Jetty/JBoss, for over a year in production. It's fast, stable, and totally free.
Never had any problems deploying ear files built in Sun's RI to JBoss - no changes necessary. We're using 2.7, and we've got 3.0 in a testing environment right now, which we will probably move to - hot deploying new databases is very nice.
JBoss is more than just EJBs - connection pooling, naming services, messaging - it's a full J2EE stack.
There are two types of people; those who divide people into two types of people, and those who don't.
Check out Computer Associate's portal product, CleverPath. It uses Tomcat as its application server. My company is testing CleverPath right now for deployment as a B2B portal for our customers.
If I were you I would let somebody else do the heavy lifting on benchmarks, where it's in production, etc. Contact CA, tell them you are thinking about deploying their portal and you want to know where it's in production and what the benchmarks are. Since CleverPath can be deployed with a third party app server (BEA, WebSphere, Sun ONE) you need to specify a native deployment for the reference customers. Since you know that the app server architecture is built on Tomcat you will have good references for Tomcat that you can use to demonstrate its abilities, or lack thereof.
In my universe I'm perfectly normal, it's not my fault you don't live in my universe.
We use Tomcat/Apache/J2EE in a production environment here with Autonomy's Portal in a Box. We've found that it performs much better than a Win32 install with the same hardware and specs. Tomcat, however, is much harder to configure and get working with proprietary software than say New Atlanta's ServletExec, which I found is much easier to configure and install. But once it get's going, I think Tomcat is as rock solid a server engine as any other.
People who have witty things here blow.
I cannot endorse the use of Tomcat as a deployment platform. Both from my experience as a user, and as a sysadmin/developer. My primary gripe with Tomcat is speed. Both from a DB perspective and general execution. Stability is also a big issue. If you ask someone if they have seen a "Tomcat java.lang.NullPointerException" in a production system, you might be surprised how many people say yes. JRun is to be avoided at all costs. I'd suggest using Caucho's Resin. It's 500 dollars a license, there is commercial support, load balancing, J2EE and most of all you will be able to reduce your hardware costs becuase it is so fast. Performance tests have shown that it's faster than any other servlet J2EE container out there. I have deployed it in a production environment and have never had a single complaint. Resin will also restart the servlet engine if there is a dump either by the JVM or Resin itsself.
- My Two Cents
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!
my company started development with tomcat and it worked well. we then moved it into production and it started to choke as we added more sites and more traffic. memory usage became a real problem (even with only 20-30 sites and 1.5GB of RAM). our application is more complex than most so perhaps you won't run into the same problem. We switched to resin (http://www.caucho.com) and have been extremely pleased with performance and support. It's relatively cheap ($500 as opposed to $40k for websphere), and it's opensource.
Tomcat is an excellent reference implementation written by some talented people. That being said, think long and hard before you deploy mission critical apps on a reference implementation for two main reasons:
- speed.
- reproduction of any errors/ill-thought out concepts in the spec.
I dont have much experience with Jetty, but consider taking a look at Resin http://www.caucho.com
Its fast and it cost $500/server (flat fee) with source code and free dev licenses.
At my last job, we used Tomcat to serve out servlet pages that were requested from Set Top Boxes that were used as a form of Electronic Programming Guide. It was fast though the previous versions of Tomcat that we were using (granted it was still fairly new) was hard to configure and a lot of tweaking by hand. This was all later on automated when we wrapped the Tomcat inside a MSI installer and ran it on a Win32 platform. By then, it has gotten somewhat more stable than the previous version. That was the last that I had heard before I was canned.
The only caveats I have for you are to be sure that you use the groovy built in connection pooling for your DB resources, and that you tune your JSPs before going into production.
Good luck!
Do those tools include a standard file or string which can be looked for with search engines? Sites might change those to avoid leaking information, but some default installations could be detected.
We're using it as a frontend to a _big_ Telcom system.
Just a thought.
--Me
I was volunteered to evaluate application servers to replace what we had been using (New Atlanta's ServletExec).
Their main interest is in speed and scalability... and the $0 pricetag of Tomcat is also of interest to them (though not critical).
I've been testing Tomcat as well as Caucho Resin (www.caucho.com) and have found Resin to be much faster and feature rich, but my bosses are actually pushing for Tomcat because it's open source and free. I think mostly also do to the (hopefully) larger installed base so peer to peer support will be more of a reality.
BTW: Does anyone know a decent... free package that can script through a complex website (logins cookies, javascript) and load it down to test for performance? They want to see numbers of both of these and I have till friday!! eek.
And, for those using Tomcat and JSPs, you are probably doing something illegal.
That is, if you use javac to compile the JSPs, which is the default for Tomcat.
Go ahead, read the j2sdk license, you are not permitted to use the j2sdk for such (commercially) purposes.
Using Jikes as the compiler is ok.
We've tested both Tomcat and Resin, and decided to go with Resin for several reasons.
.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!!!
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
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.
...on the topic list page?
.NET
An advert for Visual Studio
LOL
Bob
Listen to my latest album here
We're using both Tomcat and Jetty in our environment. They're both packaged as part of commercial products. Unfortunately both have to run on the same server. Two Java web servers on the same machine (yech!)
The company I work for is putting [some state]'s circut court data online. We handle about 13k searches per day, only 8 counties are up so far. We have used tomcat exclusively with great results. At our current peak during the day we have about 1000 hits per hour on a little over 1 million court cases. Obviously this isn't much in the grand scheme of things, but tomcat has been quite solid. This thing that we have found to be the best feature so far are the tools that are available for working with tomcat. OptimizeIt suite, Netbeans, Ant. There are RPMs out there that set up tomcat4 as a service runinning under a non-root user, and vastly improving setup.
We love it,
-jj-
Over a year ago I looked at Tomcat and found that it works ok, and the speed of 4.x was ok, but it was a real pain to hook it in to Apache.
All I wanted to do was run JSP's. I wasn't looking at EJB's or even coding my own servlets. (Yes I know a JSP becomes a servlet, but what I mean is that I never plan on using one of my own servlets).
One thing that you need to consider is that Tomcat kinda sucks as a web server. You will probably want to hook it in to Apache. I hope that it hooks in to the 2.x series of Apache, but I don't know. I do know that it is a real pain to hook it into Apache 1.3.x. What I found is that you generally want you web server to be able to handle all kinds of weird stuff like PHP, Perl, SSL, Virtual Domains, and not to mention good logging and administration. Tomcat was never designed to do that.
I chose to go with resin http://www.caucho.com. It provides a FAST JSP/Servlet runner and it is a SNAP to hook in to Apache. The thing is solid as a rock and it cost less than $1k. You get good support from a company and I was up running in less than a few hours. I spent a couple of days getting JRUN/IPLANET/WEBSPHERE/WEBLOGIC and Tomcat running.
For us it came down to Jrun, Iplanet, Tomcat and Resin.
Here is my opinion of the products for our company that does less than 1000 transactions a day.
Jrun - Good product, but the Linux version seemed imature at the time. Also, I am not sure what their long term strategy is with Java.
Iplanet - Version 4.2 was just out. I had numerous issues with this product. I would not use it. The only nice thing is that it does provide a good web server with the JSP/Servlet runner for around $1,500.00
Tomcat - 3.x 4.x - It is a reference implementation. It obviously is being used by some businesses in production, but the product as a whole was not designed to run this way. Although you only need to do an initial setup once, it will be a real pain. Don't use this as your primary web server!
Resin - Is not J2EE certified, I believe it can to CMP Entity bean, but so what. The thing ROCKS, solid as a rock, easy to setup and cost nothing for development and only around a grand for production.
Hope that this helps.
p.s. I did look at JBOSS also, but that was well over a year ago. I would have to give it serious consideration now. Our company is just getting starting with some EJB development and because of that constraint, JBOSS will probably be the way we go.
My development environment is Oracle Jdeveloper 3.x and 9i on Win2k. I have had no major issues moving code from my development box to test and production. The JSP front end stuff is done with DreamWeaver Ultradev 4. BE VERY careful about what HTML editor you use, a lot of them will delete your JSP code in the page when you move objects around! Some of them like HotMetal Pro won't even work with it.
If anyone knows of a good WYSIWYG HTML editor for Linux that works well with JSP's let me know, I would love to switch from Windows to Linux for development.
Steve Michael
steve.michael@performancestrategies.com
My company use JBOSS for production server with very good results.
The subject says it all. HP's E-services
division uses tomcat in many of their
public-facing sites. This is significant
because HP owns/used to own bluestone
application server and are now in bed with
BEA. Nevertheless they are using tomcat in
production for real e-commerce sites right
now.
--chuck
haha your blood pressure doubled and pulse rate jumped 15 points, call it your exercise for the day.
the latter being their Java Develpment Environment. Tomcat is also shipped with many other product of SAS.
In Germany I know at least two companies that use Tomcat in conjuction with SAS® Strategic Performance Management.
Unfortunatelly they do not offer a good basis to judge scalabilty of Tomcat, because the product only addressed reporting needs for a limited number of executives.
I believe many custom build internal systems here at my workplace are also running on top of Tomcat, but I would have to inquire about this.
DISCLAIMER: I am an employee of SAS.
I would hope that you have the in-house ability to test your application in the things that matter to your boss. For example, if you expect high load, you have stress tests, and so on.
So run multi-day tests on each of the different servers you are considering. Compare the results. As you can see below, there's wide ranges of opinion. I suspect that those differences in opinion are due to different applications surfacing different problems, people having different expectations, and so forth.
These comments provide at least some evidence that Tomcat can run in production. So really, find out what works for _you_ best before pushing for it's adaptation. And then you'll have data that says, "X will work best for us". That will goes miles toward convincing the boss to use X.
Who knows, it may even convince you that Tomcat isn't the right choice (if it isn't). Rather than tie your reputation to Tomcat because Tomcat is Open Source, find out what really works best. Better for you and the company.
Also, you might check the Netcraft reports; they may help convince the boss that these things are real. Not to mention the various companies' marketing groups.
mahlen
Old age is the most unexpected of things that can happen to a man.
--Trotsky
honestly, im quite agitated by the lack of understand for the use of java in the enterprise. i am a coder in a multitude of langs (as are almost all of us). my personal favorite still remains as C, but as of now, i am working as a java developer for a fortune 500 company.
:)
java's main power is its flexibility; not only in its extensive api support, but also in the fact that it when used correctly, it is 100% platform independant. ANY time you have a substatial services platform, this is incredibly important. (ie. developers on ix86 boxen vs. servers running sun4u and such other ilk).
using common lisp or c++ for a scalable and distributed platform?? are you mad? the servlet specs ensure a common platform regardless of what vendor you choose; this is VERY important for drop deployment and other various aspects. not to mention, it ALREADY takes into account such things as app server clustering and session availability.
java is by no means slow - in fact, with some operations its very fast and highly optimized. most of your overhead is caused by jvm startup costs etc... and yes, of COURSE native code is faster, thats a no brainer - but to create any type of unified platform, it involves cost.
-- the actual meat --
anyhow, as far as the reply to jetty vs tomcat, i have found the following (this is based on realworld observations and high traffic loads)
tomcat does not scale or perform that well. sun is using it for its basic servlet product (which will be jammed out later this year.) i used to be a die hard tomcat user until a developer here at work turned me on to resin. resin is VERY fast, it scales very well, and has a good developer base (bugs are dealt with in a matter of hours).
ive heard good things about orion as well.
you may also give thought to running an apache cluster to sit in front of your app servers to protect them/increas performance for static content.
i am now playing jetty, and it seems to be relatively minimalistic (which of course appleals to my unix branded C mentality) and somewhat fast. but more importantly, it integrates seamlessly into jboss, the server we use for our ejb deployment.
if you to choose between tomcat and jetty, id probably go with jetty, but at all costs, look at resin or orion as those really are the known (in the java community) as two of the better app servers out there.
just a thought, and thanks for your time to hear some good ol' pent up java slashdot angst
When I was Director of Advanced Technology at a big e-commerce site, I choose Gefion's LiteWebServer.
http://www.gefionsoftware.com/LiteWebServer/
I tested in against every servlet/JSP engine out there, and it did as well as anything else.
In particular, we bought IBM hardware, so they tried really hard to sell us on WebSphere. They had to admit that the benchmarks they kept quoting didn't reflect the kinds of things our site was doing. So, they invited us to do some performance testing at IBM's facility with IBM consultants. They still couldn't beat it.
(Which just goes to prove that a servlet engine really isn't all that complex a beast, and as long as it is written in Java, they all have the same limitations--those of the JVM & OS.)
When I left, we were considering moving to tomcat, but it was still pretty new then. I wasn't convinced the change was really necessary, though.
In any case, I signed things that prevent me from devulging what company I'm talking about, so, unfortunately, I can't give you a contact.
I was involved in a project last year for [a major German telco] which built a portal for mobile phone dealers, using Apache & Tomcat on Solaris. All fine and stable, and quick although it's not really a high transaction load environment (only a few thousand mobile phone dealers in Germany) so I can't say anything about performance under heavy loads.
We did see one of the key benefits of Open Source - found a bug in Tomcat during development, where it would crash if it received an http parameter string whose length was an exact multiple of 2k. We had a look at the code and found this was due to some dodgy-looking complicated stuff it was getting up to with pointers into the string buffer. (OK, not pointers really as it's all in Java - but the code in question looked as if somebody was trying their hardest to ignore the fact that they were using Java and write C instead). We didn't write & submit a proper fix - the code was nasty-looking and even had a comment saying "all this needs to be re-written from the ground up in the next version", but at least we were able to do a quick'n'dirty fix for our own purposes (bigger chunks of buffer allocation) and carry on without having to wait for a vendor to fix the bug many months later.
We're currently doing a major enhancement to the same project, this time still using Tomcat as the servlet engine but with JBoss rather than standalone.
A client I've worked with uses Tomcat fronted by Apache (to serve images and static content). Unfortunately, the connector between Tomcat 4 and Apache wasn't up to snuff, so we had to fall back on Tomcat 3.3.x, but it's been working great so far. I believe we've loaded tested the application running on Tomcat and on a small sun box it can handle 600 simultaneous users without falling over.
Hope this helps.
- A stable product release on a CD
- A book (preferably an O'Reilly book (;-)) on it
- Someone who would provide support for money
So we added gcc one quarter, included the information about getting the three items above, and no-one objected. So I signed up to work on the Samba book!davecb@spamcop.net
We have just put into production our own IM client based off of jabber. For the file transfers, we are running Tomcat on top of jakarta. Haven't seen a LOT of users pushing files, but our load test results seemed satisfactory.
--JamesT
--Chemguru
I've been working for a company a while now that uses Tomcat as it's sole application server, and it runs fine for us. Just a handful of servers provide for hundreds of users without a hickup. We are advantaged to have very good developers, which is the key to any application server.
No matter what application server is, BEA, NAS, ASP, ColdFusion, Tomcat, Jakarta, it all depends on how the code is deployed. Bad code makes or breaks performance. What kind of platform the code runs on has much less to do with performance than what kind of code.
I've seen ASP zoom and I've seen ASP choke on 11 users. The difference was not that they ran on Microsoft (although it's always fun to jab them), but rather the developers who used horrible routines and memory management, and created a monster that couldn't sustain more than 11 connections.
- Sonic MQ
- Tivolli NetView from IBM
- Subscriber Edge Services platform from Cisco
- JBoss
- JXTA
There is high quality professional services and support available for it, plus a helpful community.Definitely look at resin from caucho.com. It's a fast, cheap JSP container and makes a great client for app servers.
My team implemented a very computationally-intensive app with a JSP front end using resin & jboss. They saved the day - nothing would have been done on budget without them. And they worked extremely well in production environments.
BEA lists the IBM JDK as their platform requirements for the Linux platform. We found that Tomcat 3.3.1 / IBM 1.3.1 would serve around 1.2 million page views a day on a dual proc Linux machine.
I don't care what anyone says, this is definately ready for prime time, and in fact was faster than BEA WLS5.1 running on E420Rs.
"The similarities of sysadmins and drug dealers: both measure stuff in K's, and both have users."
Jetty has also been integrated with the Jonas J2EE server.
We just finished some benchmarking on our internal app-server. we found that tomcat ran 2-4 times slower than BEA/resin. Before we knew about resin, the cost of buying the extra hardware for tomcat was greater than paying for the extra BEA licences. That said.. we found resin, it is just as fast as BEA in our tests, and we are looking at using it and saving some $$$
We use tomcat exclusively. We have tried a few others but we have settled on tomcat. First reason is that when the project was kicked off, tomcat was free and it allowed us to trial the technology. Tomcat proved usable in the development environment and did what the development / design team wanted. As it got nearer deployment time a decision was taken that we had timescales to work to and all of the testing had been done with the webapp running under tomcat. We have since been using it in a live environment for nearly 12 months and (currently) have no problems with it. We use both tomcat 3 and 4. We had a few teething trouble to start with but that was more down to our lack of experience in general with running a java web server. One of the major beneifts I see in using tomcat specifically and open source stuff in general is support and product information. Although commerical companies give you a number to call if stuff goes wrong with their product, freely available information on the net is less prevalent. So you are dependant on the number of people available in their support department and the skill of the tech support you speak to. The likelyhood of you doing something brand new that has never been done before is remote. What is more likely is that you are trying to do something that isn't in the install docs but many other people do. And where open source works better is that you are much more likely to find help on the internet to boost your understanding and resolve your problem. This will make your able to respond to your businesses requirements quicker and more confidently. The other thing that commercial products tend to offer is "pretty" GUI's for configuring software. Aside from the support, this is the only thing that a commercial product will offer you that tomcat won't (same thing with apache vs. zeus). Now that is up to you really. Personally I think that as long you should get an understanding of how to configure tomcat then that isn't really a problem. I would personally have no qualms about recommending tomcat to anyone.
The Romans didn't find algebra very challenging, because X was always 10
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.
The 3.2x were really, really sucky under load. There was also a recusion problem of some sort - if you sent a GET then close the recieving socket - it may not have been this exactly, but I recall pressing & holding CTRL-R on 3.2.2 (IIRC) caused CPU usage to rocket to 100%, and eventually you'd get a stack overflow exception.
This got fixed in 3.3 and upwards (post-refactoring), which is what I'm using now. Now it just logs an IOException + stack trace, which is no less gracefull but doesn't chew memory. I'm waiting for 4.1 before switching.
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!
The web GUI inside Veritas Cluster Server (Veritas' high-availability manager) is Tomcat with a wrapper around it. Plenty of people are using this software in production.
What about TP monitors?
I have never been able to find a real free TP monitor.
I see everyone going nuts for application servers, but the fate of most of them is to suffer under high loads. I've never seen any of them incorporate the lessons learned by hard experience during 30 years in the TP monitor field.
This to me seems like the whole OO and Web fads: everything has to be OO and HTML and HTTP, and XML too. But few people learn the fundamentals. So they go and build beautiful applications on Java, HTML, MySQL, without ever realizing its unreliability or all the duplication of effort necessary. Or the risks for lack of scalability.
This is yet another thing the proprietary world gets not so bad as the free software world. For example, BEA's WebLogic Enterprise actually embeds the Tuxedo core to provide TP monitor services; they call it BEA Engine.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
BES uses Tomcat and Apache. That combination seems to work well for them and their performance seems pretty good.
From what I understand though, they did do some customisation on Tomcat for performance.
We dumped BES though, not because of Tomcat but because BES is unaware of something called the EJB SPECIFICATION. Now we go with the boss, JBoss!
I submitted this as an article, but I guess it didn't make the cut:
I am glad that you feel that Tomcat is J2EE compiant, but...
It's not. It is a Servlet / JSP engine, and not a J2EE server. If you want to integrate Tomcat with JBoss then you have a nice J2EE platform.
Sorry, just needed to straighten this guy out.
~Ab
Tomcat is slower than Jetty in all cases that I've seen (I've not seen them all, so test it for yourself). Tomcat wants to be restarted everytime you deploy a new context(or I'm just stupid and don't know how to set it up right). Jetty is an embedded small fast implementation, that will run on it's own, but I recommend JBoss! With JBoss, you can create good war or ear files that you just drop in a directory to make things work. No hassle unless you can't write a simple deployment descripter and use jar, in which case you have bigger problems. If you think JBoss will use too much memory, you can just disable all most of it's services and it will be just fine. JBoss loads in anywhere from 7s (minimal services on fast machine) to 60s (all services on a ~400Mhz machine with 64+ M of ram, UDMA enabled on your hard drive, and IBM's JRE). Get a copy of JBoss and play with it. The only reason to run Tomcat is if you want to run Apache (because you like the way it does virtual hosts or you need PHP or modperl for some other project).
Java on Linux is a complicated thing to get good results from. You need a good VM, and the one's from Sun are getting better. I recommend that you take a look at IBM and JRockit as well and compare them for your own use. They are both have no cost, but are pretty fast. JRockit is pretty robust. I use the Sun VM now just because I need 1.4 features.
Karma Clown
The only problems in my eyes with Tomcat, are its handling of updates to any war files. It seems to just miss new changes 75% of the time.
The other problem is its lack of JDBC Pooling for DBs such as MySQL or Postgres. Let's just say, there is no connection pooling. We ended up with using only one connection until we had time to roll our own.
1;
If speed your concern for static content, put TUX in front of tomcat. No config changes are necessary for tomcat and TUX can saturate gigabit ethernet adapters easily and with comparatively little CPU overhead (more CPU free for tomcat to handle the dynamic stuff).
You can read more about TUX here.
- I don't need to go outside, my CRT tan'll do me just fine.
We are using Tomcat but haven't really put it in any large, production environments, though i've heard complaints about Tomcat not being industrial strength. My understanding, however, is that the next release, which is in 4.1.x beta releases now, is much more focused on performance improvements and we've seen it perform better than 4.0.x and 3.x versions.
Also, I've heard a few people rave about Resin and say that it's really fast.
http://www.caucho.com/
We've been porting an app from SilverStream (complete pos!) to JBoss. Originally we used JBoss/Tomcat, but have moved to JBoss/Jetty since the Jetty guys have been much better at supporting features via JBoss.
;-) Never thought I'd see the day ;-)
I would recommend against straight servlet/JSP development. Using EJBs, you get portability to different user interfaces, data source pooling, transactional integrety, and a larger choice of security options a la JAAS.
Since we're working on JBoss, I can write message beans for JMS systems, I have a built in timer mechanism, I can hot deploy by copying my ear file to a directory.
I can federate enterprise wide Directory Servers (LDAP via JNDI) and Databases, integrate with MessageQueue systems (MQSeries), tie in with CORBA apps and manage everything via custom JMX apps.
Jetty was also easier to work with in the development cycle, we didn't want to unpack the ear and war and redeploy the EJBs every time we changed a single HTML tag in a JSP, so I wrote an Ant target that copies the JSPs and associated stuff to the Jetty temp dir where Jetty does a great job of finding it and recompiling it.
Tomcat's temp dir structure was too dynamic and unpredictable to do this. I've also found more options when configuring Jetty via JBoss than Tomcat (you don't use the std config xmls, they have JBoss specific ones that JBoss parses and passes on to the Web Container).
The other beautiful thing about JBoss is the JMX. JBoss is really a JMX 'spine' with the EJB Container and Servlet Container (Jetty or Tomcat) as interchangable JMX MBeans. You can provide your app way more in the way of services.
Also Jetty supports clustering, real session clustering in JBoss.
JBoss has also integrated Apache AXIS so you can expose your EJBs via SOAP if needed. (I still hate SOAP though) Using EJBs I retain the flexibility of my user interface, since the data model and business logic are in EJBs, I can write a GUI client with relative ease, or expose my EJBs to a CORBA client via JacORB (also integrated with the default JBoss install).
Some things to also look at if choosing the J2EE path:
Apache Struts or Jade for web user interface development
Xdoclet for generating your EJBs and maintaining all those XML files in your source code (web.xml, jboss.xml, struts-config.xml, ejb-jar.xml, etc.)
Ant, become one with Ant, you'll thank yourself later.
http://sf.net/projects/middlegen
Middlegen, point app at database, generate CMP Entity Beans and basic CRUD ops in struts, write business logic, then user interface, done with new J2EE app.
ArgoUML and UML2EJB
Create a UML diagram, generate EJB code. Still a work in progress, but very promising.
With all the development in code generation tools, I'm in danger of becoming a point and click programmer on Linux
Downsides, XDoclet and Middlegen are lacking in docs, Ant has a lot of useful, poorly documented tricks, JBoss could use some more docs too, or at least better organized ones... (I even have the subscription docs)
Believe me, get into the J2EE swing with all the loving Open Source tool goodness, you'll never want to touch Perl or PHP again. It just works so much nicer, and the pace of development is blinding fast. Also most of the J2EE open source projects deliver, and deliver on time.
The community is great. Mailing lists are good, IRC not as good. Sites like The ServerSide and JavaLobby have a lot of good info as well and their forums are really lively.
With JBoss and the other open source tools it's the feel of a well supported commercial environment with all the source goodness you can read, and it scales up to enterprise class systems and development methodologies, try that with Perl/PHP!
Arrogance is Confidence which lacks integrity. -- me
Sun Microsystems just released a Storage Area Management (SAN) management application based in part on Tomcat. Information is available here. Other technologies used include Postgres, Apache, and SLP. Almost qualifies for LAMP...
We used to use Weblogic but the license was becoming too expensive for our JSP/Servlet Financial Application, so we switched to Sun's iPlanet Web Server and have never looked back. They are pretty much giving away the Software now. It comes free with any server purchase (We use the cheap Netra X1 and Sunfire V100, which are about 1K) and I bet if you wanted to purchase thier new Linux Server, they wouldn't have a problem with you running it for free there as well.
-_Tony
I would recommend Tomcat for Production usage. I am the Senior Network Administrator for an ASP who has been hosting Tomcat 3.x and 4.x for two years now. The problems we get are usually small, but its always useful to have the source code available if it does get too involved. We actually were thinking about using WebSphere and even Lutris Enhydra before they went under. Both are just overkill if you are talking a non J2EE style application, but even if you are looking for Enterprise, throw JBoss into the mix. Either way you look, for the price / funtionality ratio, you cant beat it.
I would suggest you remember that Tomcat is only a servlet and JSP app server. If you want an EJB container or automatic database pooling or other additional features you may want to go with a full blown app server product. I've used WebSphere quite a bit and it works well. Web Logic is also a good choice. However, both of those products are pretty pricey.
You may want to look into the Orion app server. They have a good product with much more reasonable prices (free to developers, reasonble prices for production and test servers). We're using both Orion and WebSphere in production and they both seem to handle the load easily (I work at a large California bank with hundreds of thousands of online banking users).
Hope it helps.
In a commercial environment transaction volume
translates into revenue (or you have a broken
business model). If your transaction volume is
too high, buy another $%^@ box, dumbkopf!
By the way, your boss is obviously an idiot, so
I would suggest finding a new job ASAP.
-I like my women like I like my tea: green-
We use resin, which is cheap ($500/host) but not free and it performs wonderfully. I've played around with jetty and tomcat but they just aren't as easy to configure and their documentation, speed, and apache integration are lacking. Resin is straight forward, fast and works well. I have also heard good things about Orion Server which recently became the basis for Oracle 9i and is also a pretty good bargain at a few thousand dollars per host.
Try any of them. I use Resin. Others are happy with Tomcat. I've never heard of Jetty, but it may be good, too.
The important thing is that you write your application to the servlet spec. If you do that, switching servlet containers will be completely trivial. So if you later decide you've outgrown Tomcat, try something else instead.
The more people and orginizations that support the Apache Software fundation and it's children ie( jakarata(tomcat, catalina, ant, ect...)) the better the software will get it's already proven to work. Does anybody dispute the dominance and reliability of the Apache web server? Well then why would the same org changes it's standards for it's servlet engine and other projects? That's right all software from the Apache Software Foundation kicks ass and always will. As an org they have always provided plenty of information to use thier software in production unlike other OSS projects (no mentions out of respect). It's about fucking time that so called technology executives start to recognize good OSS projects and org's.
PS: my entire company rides on the back of the kick ass developers @ apache... JAM ON Apache / Jakarta
I like things that are sweet and not things that are lame. --
Source code on slashdot
task automatically
works its way down a source code hierarchy and compiles any class that
has not yet been compiled, or where the source file is newer than the
class file.
Feel free to adjust the compilation option parameters (debug,
optimize, and deprecation) to suit your requirements. It is also
possible to base them on properties, so that you can adjust this
behavior at runtime.
-->
-->
Open Source Identity Management: FreeIPA.org
Well that worked like crap. Basically, what we do is have a paramter you pass to ant about how you want the code configured.
Then we do a lot of copying from one directory to another using the @value@ replacements for Database pools, config files etc. Works quite welll. I do think we'd be better off writng a few custom Ant tasks for some of the things we do, but my last day at this job is tomorrow. Maybe at my next one, which is for Sun, and will be using Tomcat...
Open Source Identity Management: FreeIPA.org
I was working for a client a while back that was using tomcat in a huge production environment, but due to non-disclusure agreements that I signed, I can't give you any details about the system, or even tell you who the client is. All I can say is that it is a large financial institution that used tomcat to serve out data to several hundred corporate users. It was being implemented to replace a mainframe system. Wish I could supply some real detail.
the software could be good but how am i going to use it if it has bad documentation? I don't want to beg on newsgroups and hope someone provides the right answer.
We use weblogic and have found their docs are thorough.
You might want to try looking at the vendor pages at http://jakarta.apache.org/site/vendors.html
Hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
A couple of months ago I did a comparison of the various free servlet runners I could find available on the web for a product that my company provides. You may find the following useful for your own comparison:
e r: Sun Microsystems
r : Apache Jakarta Project
l oper: Apache Jakarta Project
p er: Mort Bay Consulting
Name: Jigsaw
Webpage: http://www.w3.org/Jigsaw/
Developer: W3C
- The W3C's reference Servlet API implementation.
- Java implementation.
- Development appears to have slowed significantly in the past year.
Name: Java Web Server
Webpage: http://wwws.sun.com/software/jwebserver/
Develop
- No longer in Development; End Of Life announced Feb, 2001.
Name: Apache JServ (mod_jserv)
Webpage: http://java.apache.org/jserv/index.html
Develope
- Servlet API: v2.0
- JVM: v1.1
- In maintenance mode, no longer currently developed project.
- Tomcat has replaced JServ as the Apache project's sponsored servlet runner.
Name: Tomcat (RECOMMENDED)
Webpage: http://jakarta.apache.org/tomcat/index.html
Deve
- Current production quality release: v4.0.3
- Servlet API: v2.3
- JSP: v1.2
- JVM: 1.2 (and newer)
- Advantages:
- JavaSoft's Java Servlet reference implementation.
- Integration with Apache guaranteed and central to Tomcat.
- Used in numerous commercial and non-commercial products.
Name: Jetty (RECOMMENDED)
Webpage: http://jetty.mortbay.org/jetty/index.html
Develo
- Servlet API: v1.3
- JSP: v1.2
- Configurable as standalone webserver or from within Apache using mod_proxy or mod_rewrite.
- Advantages:
- Small, lightweight, and fast.
- Used and distributed by IBM and Cisco in their products (Cisco sponsors development);
integrated with JBoss Application Server
I am working on a emulator for exactly the same reason. Terminal Emulators are a sweet spot for OSS development.
"The poet presents his thoughts festively, on the carriage of rhythm; usually because they could not walk" Nietzsche
Sweet baby Jesus on rye! $500 for a 3270 terminal emulator? Instead of convincing your bosses to buy shareware software, here's what you really should have done:
1. Leave company
2. Sell previous employer robust telnet clients (ahem repackaged standard BSD telnet) $2000 a pop.
3. Profit!
For those of you using these open source products in the enterprise, how do you handle validation for any regulatory agencies (e.g. the FDA)?
It is a pretty small system (~100 users), and for that Tomcat works very well. I have also had no problems with IIS integration, including using IIS for authentication when accessing servlets served by Tomcat.
Tomcat is a little slow when serving up very large pages (many megs), but I haven't tried any other servlet containers with output that big to see if they're any better. My main problem with Tomcat is in my development environment, I have to be careful about how I update servlets. Tomcat is somewhat flaky when it comes to figuring out when a servlet has been updated and needs to be redeployed. Often I have to restart Tomcat completely. But again, that's only in development where the software is changing often. In production I have had no such problems. I also haven't had any problems with Tomcat not following the JSP/servlet specification.
The prospect of restarting the whole server just to update some JSPs or to redeploy a web app is, frankly, a complete non-starter for most large sites.
A lot of WebLogic shops update their content regularly, often using separate content management systems like Vignette (I know...), so if the original enquirer has requirements like this then Tomcat can be ruled out right now.
To wax on WebLogic's virtues a bit (hey, gotta restore some balance!) it allows you to redeploy a whole WAR (as a single file or as individual ones in 'exploded' format), to update JSPs automatically just by writing them to the source directory, and to update other servlets using the refresh tool.
[Disclaimer: poster is an independent BEA consultant type]
The company I work for (Toronto based ASP, http://www.ragemedia.ca) is using JBoss 3.0.x -Tomcat 4.0.x bundle as application server for 20 clients. JBoss-Tomcat bundle has been very reliable and stable. We tried Resin, JRun 3.1, IBM WebSphere, BEA WLS5 and I'll admit that JBoss-Tomcat is not the fastest, but that's not the main concern there are things like standard conformance, small footprint, community support, price.
http://radio.weblogs.com/0107789/stories/2002/05/2 8/isTomcatCrap.html
Currently, we use Jetty 4.1 and Apache on our medium-level production traffic site. We absolutely love it.
Originally, we used Apache/Tomcat... but Tomcat was far too slow. Jetty is very fast serving both dynamic pages and static content. Jetty is highly configurable and easily modified with wonderful XML-based configuration files. I have Jetty configuring a part of my application using some custom/application-specific classes that I wrote. Great stuff! The days of having to code application startup stuff in the init() method of a load-on-startup servlet is OVER.
Oh... and Jetty running on J2SE 1.4 supports non-blocking I/O. The guys at Mortbay are on top of their game. I cannot say enough about how wonderful this tool is.
The only reason we still have Apache hanging around is because Jetty has a _very primitive_ CGI interface. It doesn't support HTTP sessions. It will run Perl scripts, but without the session support... it renders most CGI-based applications useless.
So if you want to run CGI-based apps like Bugzilla or mysqltool... you need Apache to do it for you. Jetty can't cut the mustard here.
Not withstanding its CGI weaknesses, I still feel Jetty is by far the best servlet engine out there. I have also tried Resin... but I don't see any major advantage of Resin over Jetty. I certainly didn't see any signifigant performance difference on my server (Dual 1.2Ghz, SCSI Cheetah, 1GB RAM).
If you want a servlet engine... try Jetty. I doubt you'll look any further once you've tried it.
is there a type 4 driver for postgresql?
Just watch out when moving from BEA to Tomcat... We use both JRun and Tomcat and I've found that JRun is more forgiving. (IE... tomcat doesn't like .jar s to be named .zip, and it's a little less space-efficient in jsp compilation. Normally, this wouldn't be a big deal, but we had a jsp page that compiled above the 64k limit with tomcat.) -- BEA may be similar, so don't depend on a perfect transition.
PS -- we use 4.0.3
I just setup Tomcat and Resin to develop a Filter that exposes our library to containers. Results: Tomcat is pathetically slow compared to Resin. No contest.
Tomcat is cool, but I find Resin (Caucho.com) to be easier to configure and use, especially with Apache.
e ssPlug>
I use Resin, standalone, on 7 load balanced web servers for one of my clients. I have been pretty happy with it. I also use it for my tiny Java web hosting biz <ShamelessPlug>(europasystems.net).</Shamel
I've used both of these products and found that when developing our product, exception reporting with Jetty was a pain to decipher. Tomcat, OTOH, has really nice exception reporting and is thus a pleasure to develop on.
For deployment, Jetty is small nice and lightweight. Also, if you plan to use customized tags, last I checked (9 months ago), Jetty didn't support them.
BTM
That was the turning point of my life--I went from negative zero to positive zero.
Hi,
We use tomcat in production for a number of large systems. The systems support hundreds of concurrent users on big hardware with multi-gigabyte JVMs.
I cannot divulge my company's name, but we've been using tomcat for a long time and love it. We have also compared with Jetty and iPlanet and found tomcat performance to be comparable, if not better, for our applications.
We've found that we end up deploying the same applications multiple times, with restarts, in order to get the thing working correctly
Ugh. That should not happen at all - I'm working with news sites that redeploy and update several times a day on WebLogic.
The process is complicated, particularly in a centrally managed/clustered environment - your consultant needs to understand precisely what goes on so that servers don't accidentally share temporary directories, the component is targeted at the right thing etc. etc. It's a bit arcane, but not unreasonably so.
What's the central management console in JBoss? I didn't think it had one.
Use manual deployment? This is the standard recommendation for WebLogic environments.
Seems rather like you're cutting off your nose to spite your face.
The company Zanvas that my cousin owns is doing some great stuff with Apache/Tomcat.
We ran on Tomcat without Apache, it worked very well. Unfortunately, the company went the way of other .coms, but the technology behind the company was fundamentally sound.
All the creatures will die, And all the things will be broken. That's the law of samurai. (Jubai, 1605)
Oracle Application 11i, with the latest patch level of 11.5.5 uses Apache/JServ exclusively for it's web/servlet serving. Before the 11.5.5 Oracle had some custom WebDB listeners that they used, but since then have migrated fully to the Apache/JServ combo.
Even Oracle Database 8i installs Apache and Jserv with demo servlets to connect to the oracle database.
So any corporation running Oracle 8i or 11i is using Open Source web and servlet servers in a large scale production environment.
I've got just one datapoint:
We were deploying a commercial application which was shopped by the vendor with Tomcat. As this is the way the app was installed by the vendor we counted on running that way in production.
In the weeks before the official production started we were hosting the classes for the future users. This was the first time we had more than the three developers online at the same time and it failed miserably. We had to restart tomcat every 45 minutes !
As I had previous good experience with Websphere we decided to switch over and this solved our stability problem at once. The first three months it just kept going without any intervention. In the meantime I've added preemptive weekly restart to cron to be on the safe side.
For our environment Tomcat (V3.x & V4.x, I've tried several incarnations) was not stable enough for production. I'm still a bit stumped about this, the app was shipped with Tomcat by the vendor. This might have to do with the hardware (IBM pSeries), I don't now.
Markus
We use Tomcat at the company I work for (~55k users).. Our Tomcat 4 servers (Tomcat/Apache combo) have always had a flakey feel to them and seemed slower than they should be (bad enough that I have a cron in place to restart one of them when it dies on me). The previous Tomcat 3 versions were not so bad but just don't meet the requirements any more.. I'm currently replacing the systems with new ones running Resin - Testing Resin has so-far proven to be positive (very fast/easy to configure - integrates well with Apache).
PR
No they don't - check here.
What's much more interesting is that Linux on Intel (OK, and probably Wintel too) is the prime focus of BEA's own JRockit VM.
With Sun, IBM and BEA all investing heavily, the outlook for Java on Linux has never looked better.
We have used Tomcat in production since v. 3.2
4.0.4 is the only version I would really say is rock solid though, and we had puzzling cases where the CPU would go to 100% usage and stay there under earlier 4.0.x - this is under NT, so its probably bugs in the OS/Java implementation anyway. I never had this problem running Tomcat under Linux.
Overall, I have been very happy with Tomcat, whether integrated with Apache or standalone.
You might as well at least try Tomcat before a commercial Servlet engine, and you'll probably find there is simply no need to look anywhere else.
I gots ta ding a ding dang my dang a long ling long
PHP runs better. Faster response. Less overhead as far as CPU/memory usage. Greater availablity of code snippets on the web to shortcut deployment. PHP isn't just nuke. It's supported by a large company, and really works well. If you want to fully implement the features of Tomcat go with Zope. Even if you purchase Zope services from Zend Corp. you'll find that your return on your dollar is much, much higher. Especially since the load is lower on the server and as a result you can serve a greater number of users with the same box.
I'm sorry, I'm to tired to be witty at the moment so this message will have to do.
At my company we use all three. Tomcat works fine, but the admin tools make it difficult to admin if you have lots of machines. We use Tomcat for small projects. We use WebLogic (6.1 and 7.0) because the clustering works nicely and it is easy to admin large numbers of machines. Some of our HR software requires websphere which is my least favorite in that it is not free and is not as easy to admin large numbers of machines. My thought is get it free or get the best. If you code smartly you can use tomcat for a long time. Once you system gets larger than 10 machines you might want to look at WebLogic. The in memory session replication works really well so that you can cycle machines with out lossing session. Also the built in jdbc connection pooling is a nice add. You can build multi-pools to distrubute jdbc load or for high availablity. I haven't had more trouble with tomcat or WebLogic in terms of up time. They both have minor bugs that you can work around. This is all running on Sun or Linux boxes. We use Oracle and postgresql. I don't care who makes the tool, just use the right one for the job. You will have to weight your budget vs support vs ease of admin. Getting someone who knows how to operate WebLogic = easy. Getting a Tomcat ninja is a little harder. If you plan on sitting on the server your whole life then use what ever you want. There is something to be said for being able to get away from the office and know that your admins have someone good to call if they get in trouble. WebLogic support is great. If you are running a 24x7 application, it is worth it. If you have a small shop and down time isn't going to cost your head then try out tomcat. See how it does for you. Code smartly so that you can port if you need to. There are other free app servers out there. I think HP released their app server for free. Oracle app server is SUPPOSED to be free. I have a feeling that going with Oracle will cost you even if they give the sever to you for free. Nothing is really free with Oracle. My final bit of advise is don't over build. Spend your money wisely and get hardware.
probably anyone using Tivoli Network Management software has Jetty as an application server since '99. :)
The company where I work just implemented Cardiff Software's Liquid Office online forms software, and it only runs on Tomcat. We've had some minor issues getting everything installed and getting Tomcat running, but once it's running, Tomcat has been fine. We've experienced no problems with Tomcat. We're running it on the same box as an IIS-based intranet, an IIS/MS-friendly content manager, and a web-based interface to our document imaging system.
The box I'm running all this on is a dual 933 MHz PIII box with 1.5GB of RAM and four 18GB 15K rpm HDs in a RAID 5 array, running Win2k Server. Performance is downright snappy. LiquidOffice is using LDAP-integration to authenticate users out ActiveDirectory, too.
Would I love to be running all this on Linux or Solaris or HP-UX or whatever, with some sort of high-quality LDAP-based directory instead of Win2k and ActiveDirectory? You're damn skippy I would. I hate Microsoft, but I have a lot of stuff I have to run that I don't get to choose and most of it doesn't yet run on anything except Microsoft.
Just for the heck of it, I put Tomcat on my home PC (600mhz athlon - redhat 7.2) over dialup and tried working with servlets. A friend of mine pulled 'em up and said it was just as fast as any other website on the net. Tried that with Apache? no luck at all. Interesting (for me anyways)
Did you know the food bank gives out free food?
I am very thankfull
I don't need to write haiku,
for topic reply.
The Kruger Dunning explains most post on
My company (Computer Associates-- I know, I know...) uses Tomcat as the core for a number of products that we resell to clients. CleverPath Portal and CP ECM to name a couple. We find that it does pretty well-- reliability is excellent, and since we can 'pseudo-cluster' our products it's extremely scalable. We've companies running it for 50k+ users on the tomcat base, but for heavy traffic (1000+ concurrent, heavy use connections) we usually reccomment one of the more robust engines like WebSphere or Weblogic. Check out the webpage and give me some work... ;)
Well, it's pretty good actually, no need to put Apache in there just for that - it creates an access.log file just the same. Check the Server HTTP Logging help page. Only thing it doesn't do is merge the access logs for you across different servers in a cluster like it can do with normal logs - too much traffic I guess.
Filters appear in WebLogic 7 (they came in servlet 2.3 I think) - you write the class and then mention it in the web app deployment descriptor, e.g. using WebLogic Builder.
I was at a recent Sun Developer night (in Sydney). It was announced there that sun now giving away iplanet for free. So if you want an industry strength solution I would choose that over BEA.
Jetty uses the Tomcat Jasper JSP engine, which is slow. Jetty's HTTP server is faster than Tomcat's, but tomcat is meant to use an external webserver, like Apache.
I recommend using Jboss 3.0 with integrated tomcat. It's the most popular application server on Earth, it's free, and it is entirely standards based. It is even using the LGPL license which means you can do pretty much whatever the heck you want with it.
:) (hehe, I can feel the anger coming).
As an aside, you'll never want to move your Java over to UNIX. Ironically, Microsoft does not support Java but Java runs nearly twice as fast on Windows than any other platform according to my own internal benchmarks. Freaky? True. Throw the IBM JIT in the mix and Windows based Java is much better.
Nobody uses UNIX anymore anyway.
... and get fairly good performance out of it. I think much of the bad press out there about the poor performance of Tomcat is due to people running it straight "out of the box" without tuning it at all. I was able to nearly quadruple my initial benchmarks simply by doing some basic tuning. I for one think that Tomcat is a great application server, especially given the price tag! :)
Greg
greg@whalin.com
Greg Whalin
greg@whalin.com
here
if you care about your job, your project, or your company, go with something like BEA. My company uses BEA now, after trying out Tomcat for a year. tuning and optimization can only take you so far - in my opinion, tomcat is no where near weblogic when it comes to performance or stability.
There's also a really important reason why you should consider weblogic or jrun - professional support. if you recommend tomcat to your company, and 3 months from now your production server keeps crashing because of a bug in tomcat, what will you say to your boss? open source sounds cool and all, but be careful where you use it.
I just launched a new ecommerce site for my parent's toy company, WJFantasy.com, using Tomcat 4.0, and we have no complaints -- seems plenty fast. We had a few problems with stability initially, due mostly, I think, to our ISP having limited familiarity with Tomcat. They worked it out, though, and we've had no problems for a while now. Admittedly, our traffic level isn't that high yet.
I have a friend who heads web development at a very large media company, and they just migrated a number of their most heavily trafficked sites from Tomcat to Resin. While I think Tomcat was working marginally well for them, he claims a 10x speed improvement since moving to Resin. More impressive still, he says they did the migration in a day and without having to make a single code change.
I have been trying to convice my large company to give OSS a chance (specifically CVS) but they want to talk to other large companies and get their take on it. What I need is a web site that contains a list of either references or quotes from large companies telling their OSS stories. If I could say that Sprint and IBM uses CVS extensively, and here is a inside contact that can talk about it, that would go a long way to opening the OSS door.
KangarooBox - We make IT simple!
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.
-- @rjamestaylor on Ello
"Apache now ships as the default web server for NetWare 6, so Novell shops: Take note. A patch is available from Apache [apache.org], and Luigi describes a workaround in his article."
But Apache 1.3 is the default version that ships with NetWare 6, not Apache 2.0
FYI, it's well known that Apache 2.0 is NOT recommended for production environments yet, and it clearly states that on Apache's site. It's still considered in a development stage. Also, the vulnerability that affected it on Netware affected it on various other platforms.
It must be nice to be so ignorant as to think this way. MS Active Directory could only hope to be as robust as NDS has been for years. You can count Netware vulnerabilities on one hand.
Oh and before someone trots out the same tired BS argument of MS is the largest installed base, and hackers always target the largest installed base... How then do you explain the ratio of IIS vulnerabilities to Apache vulnerabilities given the marketshare ratios?
My company began using it a few years ago as a replacement for a commercial JSP server that was a completely piece of crap. Compared to the commercial program it was okay, but it frequently (like once every couple of months) would lock up and require not only a complete restart, but in fact a "kill -9" of all java processes running as the Jakarta/Tomcat user.
Today we are using JDK 1.4 and Tomcat 3.x and are pretty happy. It doesn't lock up or do weird things anymore. Speed is okay; not blazing fast, but for our business, the compiling (or interpreting) of dynamic pages is not the slowdown. Database access is a hundred times as CPU intensive so speed of our dynamic content isn't really important. Our pages are fairly complex and usually compile in about 500ms.
All in all I vastly prefer coding web pages in PHP. Java is just plain clumsy for creating web content. But if you've got hundreds of thousands of lines of legacy code (like us), Tomcat will do you just fine.
Nope, "Commercial and other paid users must purchase deployment licenses" means it isn't open source.
I miss Meept.
Take a look at orionserver.com. Their latest STABLE release was released 6/2001! Since then they have released two EXPERIMENTAL versions. Since they want to do experiments over bug fixes, we have decided to move away from orionserver. Tomcat/JBoss seems to be the best way to go. I have used JServ/Tomcat-variations for several years, and in many production-sites. Tomcat has always been adequate (JServ was a bit of pain). If you really need to squeeze every last drop of performance out of your cpu, Resin might be the way to go. YMMV
All kinds of performance debates are best solved by numbers in practice. Use JMeter to mount a heavy load - equivalent 2-3 times of your known peak load - on Tomcat (configured with Apache web server) and see if it's acceptable. In practice, few sites have the load of concurrent users that Tomcat could not handle. Also, most of the performance issues come from the way apps are programmed, using a particular container vs another is very secondary and often accounts for about 5% of performance bottlenecks
Actuate V6 software (large-scale reporting) ships with Tomcat which it uses to power the included Active Portal as well as other internal processes.
We're using Tomcat 4.0.3 in a production environment (though on Solaris 2.8 E10000s/Ultrasparcs) and are very pleased with performance & stability. I should also add we're finalizing testing of an interface we developed to enable JSP/OpenJMS interactions - we're very pleased with the results to this point. Though our circumstances are unique I would otherwise seriously consider/recommend utilizing Tomcat under JBoss or Jonas...
Before an nameless evil company that makes PDA's and is named after a part of your hand bought and then closed us, we made a very complicated online calendar app for them. It scaled to handle 100k+ requests/transactions daily, and as far as I know still handles all their wireless registration, etc. We predated EJB's but we had rolled our own analagous beasts. We had started out on IIS (shudder) and after careful consideration moved to Resin. In addition to being superb, stable and fast, we found that the support that Scott (the head tech over at Caucho) was willing to give us was superb! We looked at TomCat tried it in our QA env, and it didn't hold up to even casual stress testing. Resin running on jdk1.4 with HotSpot--mmmmm, good. Responded well to tweaking nursery size etc, but ran well out of the box too.
Nothing great was ever achieved without enthusiasm
Just download the kits - they only need licences for commercial deployments.