Martin Marinschek wrote:
Actually memory consumption is the main issue for me so I'm looking for a way to disable the extension stuff. And maybe I'll have all the static stuff like images, style sheets and javascript files delivered by the Apache instance running in front of my Tomcat instance to get the best possible performance for static stuff and to remove load from the Tomcat process.I like that one, too ;)
the only performance issue left for me is then the memory issue, as
the extensions filter caches the whole response in memory before
writing it out to the client.
While IMHO it is not a big deal to have to specify two servlet filters instead of one in web.xml I'll revitalize the approved MultipartFilter in addition to ExtensionsFilter.
Oliver
regards,
Martin
On Tue, 15 Mar 2005 16:51:31 -0500, Sean Schofield
<[EMAIL PROTECTED]> wrote:
Interesting results indeed. Thanks for taking the time to test it. That will help with the performance discussion for sure.
sean
On Tue, 15 Mar 2005 01:02:49 -0400, Sylvain Vieujot <[EMAIL PROTECTED]> wrote:
To get a better idea of the performance penalty involved by the ExtensionsFilter, I did a very quick test :
$ time wget -r http://127.0.0.1:8080/simple-webapp
This just fetches every page of the simple-webapp.
With the ExtensionsFilter, I get : FINISHED --00:34:11-- Downloaded: 588,653 bytes in 70 files
real 0m2.914s user 0m0.028s sys 0m0.038s
Then I disabled the ExtensionsFilter by commenting the code related to it, and the by removing the ExtensionsResponseWrapper. The application isn't functional, as no javascript & resource would be included, but at least, it gives an idea of the performance penalty.
Here is what I get with the ExtensionsFilter disabled : FINISHED --00:38:00-- Downloaded: 269,094 bytes in 50 files
real 0m16.139s user 0m0.025s sys 0m0.037s
Yes, I was quite shocked too. It's faster to get 70 files with the ExtensionsFilter enabled that to get only 50 files without the ExtensionsFilter ! I did the test several times, but always with similar results. I guess that the explanation is that the ExtensionsFilter's buffering improves the response time, but this is only a guess.
At least, this shows that there is no performance penalty with the ExtensionsFilter, and it might even (against all expectations) improve the performances for the pages. For the resources, I'm quite sure it also improves the performances, thanks to the client caching.
The only case where the ExtensionsFilter could be a problem then is if you have a page with a slow code in the middle. It would wait for page to be completed before sending it to the client, whereas if you have no such filter (and no compression filter either), the user might be able to see the beginning of the page, before the server has finished to render the page. But still, the overall page rendering time would be very similar.
Sylvain.
-- Oliver Rossmueller Software Engineer and IT-Consultant Hamburg, Germany http://www.rossmueller.com
