Re: [Pas-dev] Apache, mod_perl and Preloading?

[Kyle R . B. <mo...@vo...>]

> Exactly.... so if you have a ton of content.. this is a win.

Are not PSP files mostly content?  Or at least commonly mostly content?

> This is also why Embperl didnt cache content. It only caches the code so
> that lots of html doesnt mean lots of memory. Serving static content of
> the disk is still fast..... 

Embperl didn't cache the template file?  It only cached the code?  What
did it do with the content break it up into multiple little files and
serve them from disk or something?

Pas/PSP creates code out of the template file, so the content becomes
intertwined with the code...

> Sorry. Thats what happens when you word salad between other tings....
> what I meant was that turning off StatINC fairly significant perfomance
> boost in and of itself. 

Ah.  So pre-compilation and disabling dynamic-recompliation and StatInc
should be _good_ things?

> > I want the memory usage of our site to be lower.  For our dev envronment
> > we've got 3 apache instances set up so we can run 3 applications and
> > keep them seperate from each other.  All those children and all that
> > memory adds up to swapping (the same box runs the 3 databases as well).
> > Our production environment will soon be just like this.  Memory reduciton
> > allows us to do more with less hardware.
> > 
> 
> So are you tuning for speed or memory size? Would it be unreasonable to
> just cut down max requests per child? Keep httpd's from caching a ton of
> content in the first place? There's also Apache::SizeLimit. You can
> control how much shared/unshared memory each httpd can have. THat'll
> help ya too.

Wouldn't the pre-compile/pre-load provide both a performance boost and
a memory reduction (for the child processes)?  There is an obvious 
overhead associated with pre-loading infrequently hit parts of the 
site/codebase, but unless the bulk of your site is mostly infrequently 
hit stuff, then pre-loading should be a win (both cpu and memory) right?

For sites that are either huge, or have vast expanses of infrequently
used PSPs/Page objects, then preloading might be worse - but if that
is the case, then maybe there are other issues at work.


> > My conclusions from our conversation and the page you referenced are:
> >   - at a minimum pre-compilation and pre-loading reduces the time 
> >     it takes a newly forked child to service requests for a given page.
> >     In the non-pre-load scenario, the child may have to perform 
> >     PSP compliation, and it may have to perform Perl code compilation.
> >   - at a minimum pre-loading helps share at least some memory, the
> >     benefits are maximized if you keep the MaxRequestsPerChild down
> >     to a reasonable level to flush memory that resulted in copy-on-write
> >     because of member variables and per-request handling duties.
> > 
> > So, overall, pre-compliation and pre-loading at Apache startup time are
> > worth the effort of writing a new startup.pl - right?
> 
> Yup. I'd say load the most common pages, set a semi-restrictive
> Apache::SizeLimit ( think I forgot to mention it before, but
> Apache::SizeLimit is nice) in your startup.pl, and lower max requests.
> Hopefully that'll get you out of swap in the short term. In the long
> term it might be worht it to figure out a hybrid psp/html page. Where
> large static content gets served off the disk but the dynamic bits are
> in a module..... 

Hrm...that's an interesting possibility.  Combiend with earlier
proposals of compile-time (psp compile time) expansion of psp code
into static content, that could provide more winnage...

Thanks for the discussion, I'm in the process of writing an alternate
startup.pl that I'll check in later today.

Kyle



-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------