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