Printable View
It's a long shot, but I figured I'd ask here...
Our company is preparing to move to a new application server for Java like Websphere, JBoss, etc... We need hard numbers, statistics, etc... about each of the application servers to help us decide which one to choose. Does anyone have any information that could help? I know actual numbers can vary depending upon system setup. Basically anything we can use as hard facts to make our decision is appreciated. :monster:
Well, I can't tell you about a range of servers, but I can tell you that I've always deployed my webapps on Tomcat and it's never let me down.
I work for a company that deals with average to high volumes of transactional data each day (several hundred thousand transactions), all of which are processed with a web service served by Tomcat. We also host Java-powered business intelligence websites for each client on Tomcat which are quite heavily trafficked (most merchants run reports several times a day and around 2-3 thousand merchants).
It's always been robust in my experience and plays nicely with Apache, which is a plus for web devs who want to serve Java web apps and also retain the modularity of Apache. When I was at uni, y professors thought highly enough of it to hinge several web programming courses on it. And it's free. :p
We run it on a couple of clustered HP dl380 servers, 64GB RAM with 8 cores each.
Does Tomcat "fail gracefully" when there's too much traffic? Our current app server (SilverStream, which is a ten-year-old, basically sunset and unsupported app server) likes to choke and go offline when we get slammed with requests, which isn't good. We're a ticketing company and out web servers usually handle the load, but we're having some issues with some new clients where we get slammed with hits when tickets first go on sale. Needless to say, this isn't good for business. We're playing with our machine and app server settings to help handle the load, but it's also time to move off of the antiquated server we're on now.
Tomcat is the only one I've worked with as well, and it worked nicely, though I can't really speak for it in production environments - we just used it for local testing, and I left before they tried to deploy it for anything bigger. I would imagine that, with it being actively developed and pretty heavily used in the industry, it probably handles itself well under load, but yeah, might wanna try the mailing list or documentation to get your specific questions answered.
Actually Tomcat has crashed a few times on us. I suspect it's a bug in the modjk module we've been using though (module used for passing requests off of Apache to Tomcat for Java webapps), so if you're running a standalone Tomcat server then I doubt you'll have the same issue we had (not to say there won't be issues but probably not the same as what we experienced. It's worth noting that the web apps we're running are very processor and database intensive (business intelligence and data mining served via a web interface, can't get much more extreme for a web app really. :p). Also worth noting is that the hardware we were experiencing the problems with was pretty damned useless (old dedicated database running solaris and a bunch of servers that would've been high-powered in 2002. :p) for what we were trying to accomplish; the Tomcat and Apache installations were old (Tomcat 4, Apache 1.8) and the Java VM was 1.4.
All this was up until mid 2009, I mean I know you're not meant to upgrade production environments to the bleeding edge but seriously. I dunno how the system managed to handle what it did for that long. :p After recompiling the web apps in Java SE 1.6, we haven't had any issues on the new hardware with latest versions of the software.
It's not really ideal, but in all cases a restart of the Tomcat fixed the issue.
I've spoken with some other people in the field and they've also steered me towards Tomcat, for no other reason that it's a cheaper alternative to Weblogic, Websphere, etc... They also suggested starting off with Tomcat and see if that works, and if not, work your way up. The only problem with this process is that we don't want to learn in production that it doesn't work, but rather in a test environment. Thankfully we have some programs that can simulate thousands of hits per second, so that might help us determine the best app server in our test environment.
Thanks for the feedback!