W3C home > Mailing lists > Public > public-qa-dev@w3.org > February 2008

Re: mod_perl memory usage

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>
Message-Id: <200802050052.05649.ville.skytta@iki.fi>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 19 August 2010 18:12:48 GMT