> -----Original Message----- > From: Koes, Derrick > To: '[EMAIL PROTECTED]' > Sent: 3/26/03 6:13 PM > Subject: overhead running from war rather than unpacked > > > How much overhead is there running directly from the war file rather > than > unpacked? > > Thanks, > Derrick
On Wed, 26 Mar 2003, Sterin, Ilya wrote: > Date: Wed, 26 Mar 2003 22:29:56 -0700 > From: "Sterin, Ilya" <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: "'Koes, Derrick '" <[EMAIL PROTECTED]>, > "''[EMAIL PROTECTED]' '" <[EMAIL PROTECTED]> > Subject: RE: overhead running from war rather than unpacked > > None??? When you deploy a war file, usually upon the start of tomcat, or > restart, the war file is unpacked, into a directory. Also, when pages are > called, they are cached within the work directory, so truly, none. > Alas, it is not quite *that* simple, but it's fairly close. Let's divide the types of requests into a number of categories, and examine the difference between running from a WAR and running from an unpacked directory (the following is generally applicable to 4.1 -- there might well be differences in how 3.x or 4.0 or 5.x do things), and this discussion also assumes that you're doing non-SSL transactions (there are performance differences in doing SSL in Java versus C/C++ code): (1) Request that matches a servlet mapping -- in either scenario, the static resources are never accessed, so directory vs. WAR is not relevant. The performance will be basically the same. (2) JSP page, first time it is accessed -- the source code of the page has to be made available as a file so that it can be compiled. This requires extracting it from the WAR if you're running from a WAR, but that is only a one-time issue. (3) JSP page, after it has been compiled -- The JSP servlet is mapped to "*.jsp" so rule (1) is fired. If the JSP servlet detects that the page has already been compiled (the class file will be in the work directory), and that the page has not been updated (this check is not made unless you turn "development" mode on), then the generated servlet class is invoked directly and it's not relevant whether the webapp is unpacked or not. (4) Static resource -- this is the most interesting case, because it happens on every request (not just once). There are two important sub-cases: (a) This is a request for a URL not stored in the browser's cache -- the resource will be served unconditionally by Tomcat. Therefore, we must compare the time to extract a resource from a WAR file (which might have been compressed, depending on how you create it) versus opening a file, copying it's content, and closing it. The latter will likely be faster *most* of the time, but you need to benchmark it for your own app+JDK+Tomcat combination to know for sure which is faster in your case. (b) This is a request for a URL stored in the browser's cache, so the browser sends an "If-Modified-Since" header with the request. - If the resource has not been modified, Tomcat sends back a "Not Modified" response (without accessing the webapp if it has dealt with this resource before, because it caches the last modified timestamp for each resource in memory). In this case, WAR versus directory is not relevant. - If the resource has been modified, this essentially becomes like sub-case (a) above. In general, then, the difference between deploying a webapp directly from a WAR or an unpacked directory primarily shows up in sub-case (a) of case (4) -- a static resource that is not already in the browser's cache (or a page that has been modified more recently than the copy in the browser's cache. Note that all of the above comments are directed at a production deployment scenario -- when I am developing webapps I *alway* use an unpacked directory (plus Tomcat's dynamic install/remove commands via the manager webapp) -- there's no reason to waste the time it takes to create a WAR in the first place when you are repeatedly cycling through a compile-test loop. ----- Off Topic, But Related, Observations --- Interestingly, this is also the exact situation where front-ending Tomcat with a web server will generally be more performant -- in all of the other scenarios, the approach which is faster is *very* environmentally dependent, so you need to benchmark your particular app to see what works better -- fortunatly, you can develop your app without caring one way or the other, and make the decision about which deployment approach to take for your production servers at the time you are ready to deploy. For production deployments, when you don't need the web server features for other reasons, you should *always* benchmark a Tomcat standalone deployment versus deploying with Tomcat behind a web server. In many cases, you'll find that the Tomcat stanadalone solution is fast enough (which means that "fastest possible" is not a relevant decision critera). If it is, I would generally recommend going that way, because it is much simpler to configure and manage. If Tomcat standalone is not fast enough, benchmark your app deployed standalone versus behind a web server, and pick whichever is faster (if you've been at *all* careful in your application design, choosing one or the other will require zero changes to your app -- isn't that nice?). Just don't be surprised by situations where Tomcat standalone is either just as fast as the combination, or only marginally slower -- this will often happen when the app is primarily dynamic (i.e. cases (1) through (3) above, with very little static content). On the other hand, apps with lots of static content, or lots of SSL processing (where your JDK hasn't optimized its implementation of the JSSE classes), or apps that need the other facilities of the web server, then by all means go ahead and invest in the effort of installing and configuring the appropriate web connector. Just be aware that you are not being forced into this decision; it just so happens to work better for you. That is one of the very nice features of using the Java platform for developing dynamic web apps. One suggestion -- if you hear someone tell you that Tomcat standalone is *always* faster than Tomcat behind a web server (or vice versa), please smile tolerantly and bite your tongue so you won't laugh at the person making this statement :-). The world is never ever quite that simple. Benchmarks are your friend, if the benchmark you use is *your* application. Otherwise, they are just a distraction :-). > Ilya Craig McClanahan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]