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.

Reply via email to