I would be very careful with a claim like Ms. Smoak's, "Apache is... much faster serving static resources" as that's highly qualitative. Please provide benchmarks or tests that prove your point, because I don't think it's much faster at serving static resources.
Retraction! I should have said, "Apache is faster at serving static resources than the Tomcat/connector/Apache combination." I've never tested Tomcat alone vs. Apache alone-- Apache was in place here before I started writing webapps.
I think we can all agree that this statement is true. Certainly adding Apache to Tomcat is slower than having Tomcat do the work all by itself.
I don't have benchmarks, and I've made the statement "Apache is faster for static content tthan Tomcat" before, and I still believe it to be true. Here's why:
When Apache httpd serves a static resource, it pretty much goes through all the processing required to find out where the file actually is, and then dumps the bytes to the response. I'm pretty sure that it does all this without allocating anything on the heap -- most of the object/data structures necesary for the lookup I'm sure already exist, and the buffer for the response is probably fixed, and probably on the stack.
For Tomcat to do the same thing, it's got to create a bunch of objects which later need to be garbage-collected. I'm guessing that the Tomcat devs have streamlined the process so that not all of the ServletRequest objects and all that jazz are created every time, but you still have to create a lot of stuff on the heap (including every String used, like the URL, and maybe some headers, etc.). After that (probably after the response has been sent to the client, which is why the numbers are hard to track down), the GC has to run. I think that I can make the blanket statement that explicit memory management is faster than GC'd memory, since the GC actually to do some work to determine if memory can be freed, while the explicit scheme needs no such processing.
I am willing to concede that Apache vs. Tomcat in a direct competition for serving up static content on the same hardware will probably result in timing differences so small as to be insignificant to anyone doing reasonable benchmarking.
Lastly, if you have your architecture such that you have crappy machines in front of the application servers to serve static content (so that the app servers don't "waste" time serving static content), Apache will run must better on them since it requires fewer resources to run nicely. For example, Apache can do quite nicely on a 16MB machine as a web server. Tomcat can't really do that since the JVM is such a monster.
-chris
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
