> -----Ursprüngliche Nachricht-----
> Von: Jim Jagielski [mailto:[email protected]]
> Gesendet: Montag, 7. Dezember 2015 14:09
> An: [email protected]
> Betreff: Re: reverse proxy wishlist
> 
> 
> > On Dec 5, 2015, at 9:30 PM, William A Rowe Jr <[email protected]>
> wrote:
> >
> > On Sat, Dec 5, 2015 at 3:48 PM, Jim Jagielski <[email protected]> wrote:
> >
> > > On Dec 4, 2015, at 10:25 AM, William A Rowe Jr <[email protected]>
> wrote:
> > >
> > > My observation was that that the mapped pages for 2-6 fundamental
> socache, lbmethod or slotmem providers are the same as for a single
> module due to page alignment - load any two and you are already wasting
> kernel resources and memory.
> > >
> >
> > Since you refer to these 3 modules, what to you recommend? That
> > we bundle all providers into 1 module? That's fine with me but
> > my point was that the whole idea of submodules and providers,
> > whether from us or not, was that the admin only needs to load
> > the ones they use. This recommendation seems to ignore this
> > basic advice.
> >
> > That advise always applies if the module interacts with the user-
> agent.
> >
> 
> I have no idea why it also doesn't apply no matter what.
> Isn't the whole idea of a loadable modules is so one
> can add, or remove, functionality, no matter what, when
> it's not needed? The idea of it only applying when it (directly)
> "interacts with the user-agent" seems extremely artificial.

I guess the point is a tradeoff, between "wasting" Kernel resources and pages 
by loading lots of very small modules and being able to really only load the 
code you need.
As with all such stuff there is no real sharp line. For some one is more 
important than the other one. For others it is vice versa.
So I would go for a pragmatic approach with no sharp line. I guess we can 
bundle all balancers we deliver into one module. IMHO we wouldn't lose anything 
here.
Of course we keep it possible to have balancers in separate modules for other 
people. With other  modules I am not so sure if this really makes sense and we 
should keep it
as is.

Regards

Rüdiger

Reply via email to