Like any well planned out software project the ideal solution is derived from the requirements. There are very few broad statements such as "Maybe for large volume servers, but for smaller servers (<10 requests per second) it is NOT WORTHWHILE to do something else than Tomcat standalone" that hold true over the course of time.
Is the only requirement for a web project the # of users and traffic? I have yet to come across such a project, and I've been at this for quite a long time. What are the security requirements? Do you have any legacy cgi code that tomcat can't handle well? Will you need to add any? Are you sure? I'm not sure why people are so afraid to configure up apache. If you can get tomcat configured you most certainly can get apache running. It's much simpler (not that tomcat is hard). 9/10 times apache can be configured and running on a box in about 5 minutes if you know what you're doing. I'm currently installing tomcat/apache for a new intranet. The requirements didn't start out necessitating apache (based on load and feature requests), but I thought that I might as well just in case. There's a lot of static images, why bother tomcat with those tasks. In the back of my mind I knew that something would creep in. Sure enough, just today we decided to try to authenticate users against the NT domain. I'm sure someone out there is going to tell me how to do that from tomcat, but it will probably require a bunch of new code and be a major hassle. Guess what, Apache has a module for it (and I'm running on solaris). IMHO the software industry is full of stories about packages that died trying to do too much. OO programming is all about modularizing code. Doesn't that transfer to server software as well? Tomcat is a servlet engine. Apache is a webserver. Sure tomcat can serve .gifs, and I could write a novel in Outlook, but I'd rather use a word processor. If we push the tomcat engine towards being a fully featured webserver isn't it eventually going to bloat? Won't the task we asked it to do (handle servlet/jsp requests) wind up suffering? Anyway, that's just my opinion. Rick -----Original Message----- From: Peter Mutsaers [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 18, 2001 7:39 PM To: [EMAIL PROTECTED] Subject: Re: USE TOMCAT INSTEAD OF IIS >> "Rui" == Rui Miguel Seabra <[EMAIL PROTECTED]> writes: Rui> No. Rui> Use apache web server instead of iis or tomcat webserver. Rui> Even the configuration is MUCH MUCH easier (and safer even in Rui> default config). Maybe for large volume servers, but for smaller servers (<10 requests per second) it is NOT WORTHWHILE to do something else than Tomcat standalone. It is way easier to configure tomcat standalone than configure two programs (tomcat and apache) plus the connector between tomcat and apache. Also, if most of your pages are mostly dynamic, relaying everything through apache will only slow down compared to direct access to the servlet engine (tomcat). Only for high volume static pages I would recommend (maybe) adding apache. Maybe the optimal would be to have two servers, one for dynamic stuff and one for static stuff (the images etc). The dynamic pages refer to the other server (apache) for larger static data. Thus you get the best of two worlds: direct access to the servlets without deviation/routing through apache, and faster(?) access to static data through apache. B.t.w. SUN claims a java webserver/servlet engine should be able to reach the same performance for static data as dedicated webservers, but I haven't done any benchmarks. I can only say that after using Apache+Tomcat for our (internal) app for 10000 users at about 20 requests per second, we ditched Apache and went to Tomcat (version 4) standalone. This simplyfied configuration and improved performance. -- Peter Mutsaers | Dübendorf | UNIX - Live free or die [EMAIL PROTECTED] | Switzerland | Sent via FreeBSD 4.3-stable
