Extensions filter performance test

[Sylvain Vieujot]

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.