- From: Ville Skyttä <ville.skytta@iki.fi>
- Date: Tue, 5 Feb 2008 00:52:04 +0200
- To: olivier Thereaux <ot@w3.org>
- Cc: Gerald Oskoboiny <gerald@w3.org>, QA-dev <public-qa-dev@w3.org>
On Monday 04 February 2008, olivier Thereaux wrote: > Hi Ville, Gerald, all. Hi, > * why is mod-perl so fast? > - beats me why there is an order of magnitude in difference... > - looks like forking check was very costly after all I checked how costly parsing all the templates and config files was in the past, and ISTR it was nontrivial, something like a second or so per request in my setup back then (which probably was quite a bit slower than any of the validator production instances). With mod_perl the templates part of that is done only once -- ditto config files with ::Registry but not with ::PerlRun IIUC -- so if the number I remember is anywhere near correct, that's one major contributor. The HTML::Template docs mention 90% performance increase with mod_perl and template caching. Add a large set of Perl modules compiled on every request vs only at startup to that and I think even if somewhat surprising, your numbers sound quite possible. > Any thought on this plan? Sounds fine to me. As demonstrated by your xhtml+svg+mathml test case, the order of magnitude difference most likely won't be there in real life use as both the significant times to retrieve a remote document as well as to stream the validation results back to the client will be added to the mix. A reverse proxy in front of the mod_perl backend server should help with the latter (as well as with serving static content) but I have no idea how significant part of the total request-response duration streaming the results actually is, though.
Received on Monday, 4 February 2008 22:52:48 UTC