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