myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Vieujot <>
Subject Extensions filter performance test
Date Tue, 15 Mar 2005 05:02:49 GMT
To get a better idea of the performance penalty involved by the
ExtensionsFilter, I did a very quick test :

$ time wget -r

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.


View raw message