Howdy, Oh I hope people search the archives before asking questions. If they find messages like yours, we will get so many less repetitive questions. <wishful thinking>
Personally, I've benchmarked all ours apps deployed as an unpacked war file versus a packed war file, and the performance is virtually identical. All our apps run on tomcat standalone and tend to be servlet-heavy, light on JSPs, and very light on static contents. Kudos to the tomcat designers for the excellent war support. Yoav Shapira Millennium ChemInformatics >-----Original Message----- >From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] >Sent: Thursday, March 27, 2003 2:12 AM >To: Tomcat Users List >Cc: 'Koes, Derrick ' >Subject: RE: overhead running from war rather than unpacked > > > >> -----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]' '" <tomcat- >[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] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
