httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: reverse proxy wishlist
Date Fri, 04 Dec 2015 13:32:58 GMT
I thought the idea of providers and submodules were so
that, for example, if someone only used byrequests, for
example, they only needed to build and load that specific
submodule and nothing else... Not seeing what issue exactly
you're trying to address.

> On Dec 3, 2015, at 6:25 PM, William A Rowe Jr <wrowe@rowe-clan.net> wrote:
> 
> On Thu, Dec 3, 2015 at 3:40 PM, Jim Jagielski <jim@jagunet.com> wrote:
> 
> > On Dec 3, 2015, at 11:09 AM, William A Rowe Jr <wrowe@rowe-clan.net> wrote:
> >
> > My personal wish list is that we eliminate module bloat by coalescing
> > alternative "standard" implementations into a single module again in
> > 2.next, and not just limited to lbmethod, but also the core socache
> > and slotmem providers. Most stock/core implementations shouldn't
> > change if a user wants to plug in 'yet another' option, but there is really
> > no excuse for us to map so many ldobjects and text pages into the
> > memory map of a given process, when the actual program text page
> > of each is a few hundred opcodes, max.
> >
> 
> Not following you there... what do you mean? You mention the
> lbmethods; do you mean instead of having each method be its
> own module, making them all one?
> 
> Not specific to lbmethods but yes, one mod_lbmethod_core.so provider
> of the basic set of 3-4 methods that right now eat up a lot of 64kb process
> page mappings for no particular benefit.  The builder could even decide these
> are compiled-in to the base httpd.  We don't dismiss the loadable approach,
> we simply decide this subset is effectively baked, and then use the loadable
> lbmethod to extend yet another experimental/dynamic/evolving method, from
> the ASF or third parties.
>  
> 


Mime
View raw message