Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
MIME-Version: 1.0
In-Reply-To: <23420A92-4983-40B9-86FD-7B0681983601@jaguNET.com>
References: <288293CD-6D82-42E0-BFC9-9DC25F969ED6@jaguNET.com>
	<CACsi250e5arsm+EzN1KDJMOD-vAmTyM8M0utTuEfedUGSUfXJw@mail.gmail.com>
	<77E6470A-4FAD-4DAD-BE9E-E11F54388E2C@jaguNET.com>
	<CACsi250wpsmUsC5kEWfJOAoYKHG28m2N6NrizHXsHFjU7_nVYQ@mail.gmail.com>
	<23420A92-4983-40B9-86FD-7B0681983601@jaguNET.com>
Date: Fri, 4 Dec 2015 09:25:28 -0600
Message-ID: 
 <CACsi250w43S9-GLmPWeFAUS3wRte81tc=g3f5cWxLLf+Q7Mx5g@mail.gmail.com>
Subject: Re: reverse proxy wishlist
From: William A Rowe Jr <wrowe@rowe-clan.net>
To: httpd <dev@httpd.apache.org>
Content-Type: multipart/alternative; boundary=001a11c2eb5a0fea190526141e56

--001a11c2eb5a0fea190526141e56
Content-Type: text/plain; charset=UTF-8

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.

I agree that any user agent or content facing modules should remain
distinct - only load those you use and trust.  These core feature sets,
when used, only face the conf file or in the case of lbmethod, the admin
console.  So they should be safe to load in parallel, when leveraged for a
given module.  They should even be safe to compile static, if the user
likes.
On Dec 4, 2015 07:33, "Jim Jagielski" <jim@jagunet.com> wrote:

> 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.
> >
> >
>
>

--001a11c2eb5a0fea190526141e56
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">My observation was that that the mapped pages for 2-6 fundam=
ental socache, lbmethod or slotmem providers are the same as for a single m=
odule due to page alignment - load any two and you are already wasting kern=
el resources and memory.</p>
<p dir=3D"ltr">I agree that any user agent or content facing modules should=
 remain distinct - only load those you use and trust.=C2=A0 These core feat=
ure sets, when used, only face the conf file or in the case of lbmethod, th=
e admin console.=C2=A0 So they should be safe to load in parallel, when lev=
eraged for a given module.=C2=A0 They should even be safe to compile static=
, if the user likes.<br>
</p>
<div class=3D"gmail_quote">On Dec 4, 2015 07:33, &quot;Jim Jagielski&quot; =
&lt;<a href=3D"mailto:jim@jagunet.com">jim@jagunet.com</a>&gt; wrote:<br ty=
pe=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">I thought the idea of pro=
viders and submodules were so<br>
that, for example, if someone only used byrequests, for<br>
example, they only needed to build and load that specific<br>
submodule and nothing else... Not seeing what issue exactly<br>
you&#39;re trying to address.<br>
<br>
&gt; On Dec 3, 2015, at 6:25 PM, William A Rowe Jr &lt;<a href=3D"mailto:wr=
owe@rowe-clan.net">wrowe@rowe-clan.net</a>&gt; wrote:<br>
&gt;<br>
&gt; On Thu, Dec 3, 2015 at 3:40 PM, Jim Jagielski &lt;<a href=3D"mailto:ji=
m@jagunet.com">jim@jagunet.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; On Dec 3, 2015, at 11:09 AM, William A Rowe Jr &lt;<a href=3D"mai=
lto:wrowe@rowe-clan.net">wrowe@rowe-clan.net</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; My personal wish list is that we eliminate module bloat by coales=
cing<br>
&gt; &gt; alternative &quot;standard&quot; implementations into a single mo=
dule again in<br>
&gt; &gt; 2.next, and not just limited to lbmethod, but also the core socac=
he<br>
&gt; &gt; and slotmem providers. Most stock/core implementations shouldn=
9;t<br>
&gt; &gt; change if a user wants to plug in &#39;yet another&#39; option, b=
ut there is really<br>
&gt; &gt; no excuse for us to map so many ldobjects and text pages into the=
<br>
&gt; &gt; memory map of a given process, when the actual program text page<=
br>
&gt; &gt; of each is a few hundred opcodes, max.<br>
&gt; &gt;<br>
&gt;<br>
&gt; Not following you there... what do you mean? You mention the<br>
&gt; lbmethods; do you mean instead of having each method be its<br>
&gt; own module, making them all one?<br>
&gt;<br>
&gt; Not specific to lbmethods but yes, one mod_lbmethod_core.so provider<b=
r>
&gt; of the basic set of 3-4 methods that right now eat up a lot of 64kb pr=
ocess<br>
&gt; page mappings for no particular benefit.=C2=A0 The builder could even =
decide these<br>
&gt; are compiled-in to the base httpd.=C2=A0 We don&#39;t dismiss the load=
able approach,<br>
&gt; we simply decide this subset is effectively baked, and then use the lo=
adable<br>
&gt; lbmethod to extend yet another experimental/dynamic/evolving method, f=
rom<br>
&gt; the ASF or third parties.<br>
&gt;<br>
&gt;<br>
<br>
</blockquote></div>

--001a11c2eb5a0fea190526141e56--