Who is Using Tomcat or Jetty in Production?

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

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

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

Production Tomcat

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.

My company uses tomcat exclusively

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.

Re:My company uses tomcat exclusively

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

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

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

Re:My company uses tomcat exclusively

"If we need to deploy a new context, then restarting tomcat brings with it a 30-45 second outage."

Remember, in 4.x, a command-line admin tool to insert/reload contexts at runtime has been added. A GUI is planned to follow.

Novell

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.

JBoss

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.

Tomcat is bad but alternatives are even worse

I'm no fan of tomcat myself but if you're doing servlets then it is probably your best option (and cheapest). Being in a situation similar to yours I've evaluated JRun, WebSphere and Tomcat and liked Tomcat the most. It was most up to date with the J2EE spec and wasn't trying to be everything I didn't want it to be. It simply got its job done. Having said that, Tomcat on the back end means Apache on the web tier and I'm no big fan of Apache (or its configuration nightmare specifically).

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.

Re:Tomcat is bad but alternatives are even worse

Having said that, Tomcat on the back end means Apache on the web tier

Why? Tomcat can be used stand-alone and it can be integrated with other webservers, even IIS!

TUX!

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 [redhat.com].

Use Resin if you care about performence

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).

BEA is buggy as hell anyhow.....

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....

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

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

6.0SP2 would not honor VariableInfo.NESTED in custom tag libraries

6.1 requires the weblogic.xml file in your WAR. Huh? Why in the WAR?

6.1 will hang for 30 seconds on your servlets if you open and close the stream without sending anything on the stream

6.1SP2 to set the proper application CLASSPATH

6.1SP3 fails to handle code that translates a SAX2 event stream to HTML using Xerces (SAX2) and Xalan (XSL); I'm dead in the water with this because our application depends on SAX2 streams

Honestly, I think I have spent more time tryiing to make WebLogic work than it took to write the application in the first place!

Is Tomcat crap?

I don't know, but I archived this article [weblogs.com] when I saw it. The article contains some benchmarks made by an obvious geek, he also talks about the price.

"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)."

Re:Is Tomcat crap?

There are issues with that article that he doesn't mention. For example, what is his test page? Is he serving static content? Does he have Tomcat in "reload" mode (where it checks for updated code every time a servlet is executed)?

I can't help but think that this article is just poorly written. It doesn't really paint a clear picture of what he's using Tomcat for. He mentions nothing about the various configurations tested. It's way too easy to just write him off due to an overly evident bias against Tomcat from the beginning. (Hint: when attempting to persuade people, calling a benchmark test "Is Tomcat Crap?" reveals your bias...)

I use Tomcat at work as the development platform we use. We're probably going to be using Oracle Portal for the production system (not that I know what that is or what it uses for it's JSP engine, but...). It works fine for a development platform.

I haven't done any performance testing on it (yet), but when I get the chance, I might look into it. It'd be interesting to find out what my results are. I have a suspicision that Tomcat performed poorly in his "tests" because the other servlet engines came in an optimized for speed setting while Tomcat comes "optimized" for development.

JBoss !

JBoss [jboss.org] 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 :)

Tomcat

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.

Choosing Tomcat over others

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.

My company uses Tomcat + Apache + PostgreSQL....

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.

Tomcat is fine

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.

listen to his boss words

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.

Tomcat does suck, avoid it.

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

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

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

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

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

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

Re:Tomcat does suck, avoid it.

What the hell are you talking about?

You didn't mention what spec you mean but I think you meant that Tomcat implements Servlet, JSP etc. specs poorly?

I wonder what is your standard for poor but you can't get any better compliance than what you get with Tomcat namely it happens to be the official, Sub-blessed reference implementation of these very specs. If you're in doubt, then check these URLs: Java Servlet technology - Implementations ja Specifications at java.sun.com [sun.com] and Front page of Tomcat site [apache.org]. Thank you.

Comparisons, plus some opinions

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

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

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

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

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

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

weather.com is now exclusively Tomcat

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.

Blogger

I believe Blogger has moved from the ASP-based code that runs free Blogger to Jakarta & Tomcat....the Blogger API page [blogger.com] is a plain Jakarta/Tomcat page. According to some of the comments Evan Williams made recently, about "moving away from ASP [blogger.com]" and some of the discussion over at Blogroots [blogroots.com] point to it.

How I introduced free software into my big company

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.

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 ... 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.

Navy

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 [imdb.com] about it.

I run Tomcat in production

... and so do many of my customers. This may not be as good an endorsement as it sounds as none of the sites concerned is particularly high traffic and performance isn't really a big issue. However I've also tried JRun (fundamentally broken and useless), BEA WebLogic (huge, over-complex, bloated) and Jigsaw (very nice for small installations but last time I used it didn't yet support Servlet 2.2).

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.

Try Resin

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

Enough Tomcat Bashing... I have proof it works!

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 .html pages.
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 [ubeans.com]. 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 [jboss.org]!!! It rocks!

Complementary

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.

Resin in a production environment, plus GLUE

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

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

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

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

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

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

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

JBoss/Jetty

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.

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 ;-) Never thought I'd see the day ;-)

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!

Re:We don't get paid to do your job

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.