Mailing-List: contact users-help@trafficserver.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@trafficserver.apache.org
Received-SPF: pass (athena.apache.org: domain of moseleymark@gmail.com
 designates 209.85.223.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <24DB4B81-4198-4F1C-B28F-72F4A4CD6DBE@apache.org>
References: 
 <CAOH1cHkZaziDxokJbUPqmKCHMYK68bDLP2GRmG0hpziBP3EBLQ@mail.gmail.com>
	<24DB4B81-4198-4F1C-B28F-72F4A4CD6DBE@apache.org>
Date: Fri, 22 Nov 2013 23:13:18 -0800
Message-ID: 
 <CAOH1cH=jJx1SnRsfFiKHKBfz4yCtLn-9BjvwhHjp_EZMV49VYA@mail.gmail.com>
Subject: Re: Curious about proxy.config.remap.num_remap_threads
From: Mark Moseley <moseleymark@gmail.com>
To: Leif Hedstrom <zwoop@apache.org>
Cc: users@trafficserver.apache.org
Content-Type: multipart/alternative; boundary=089e013c68e281e5db04ebd2ddd3

--089e013c68e281e5db04ebd2ddd3
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Nov 22, 2013 at 7:51 PM, Leif Hedstrom <zwoop@apache.org> wrote:

>
> On Nov 22, 2013, at 11:18 AM, Mark Moseley <moseleymark@gmail.com> wrote:
>
> > I'm looking to deploy ATS in a very busy, remap-heavy reverse proxy
> environment. I'll be using a handful of lines of Lua to remap based on an
> incoming header.
> >
> > The new proxy.config.remap.num_remap_threads option sounds like it'd be
> pretty important to set for such a scenario.
> >
> > Could the devs chime in on what would be an appropriate # for this
> setting?
> >
> > Should 1 suffice? Should it be equal to # of cores? Or something much
> higher?
>
>
> The only use case I think think of for the remap threads feature is if you
> have a plugin that can block a thread. With block, I mean, not yield it in
> some reasonable amount of milliseconds. For now, if you use this remap
> threads processor, you also have to turn off the per thread sharing of
> sessions, and switch to a single global session pool.
>


Ok, so it sounds like if something isn't blocking, then there's no need to
set it at all then. My Lua code is just doing some munging on the original
destination IP, so should never block. Sound right?

--089e013c68e281e5db04ebd2ddd3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Fri, Nov 22, 2013 at 7:51 PM, Leif Hedstrom <span dir=
=3D"ltr">&lt;<a href=3D"mailto:zwoop@apache.org" target=3D"_blank">zwoop@ap=
ache.org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"=
gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5"><br>
On Nov 22, 2013, at 11:18 AM, Mark Moseley &lt;<a href=3D"mailto:moseleymar=
k@gmail.com">moseleymark@gmail.com</a>&gt; wrote:<br>
<br>
&gt; I&#39;m looking to deploy ATS in a very busy, remap-heavy reverse prox=
y environment. I&#39;ll be using a handful of lines of Lua to remap based o=
n an incoming header.<br>
&gt;<br>
&gt; The new proxy.config.remap.num_remap_threads option sounds like it&#39=
;d be pretty important to set for such a scenario.<br>
&gt;<br>
&gt; Could the devs chime in on what would be an appropriate # for this set=
ting?<br>
&gt;<br>
&gt; Should 1 suffice? Should it be equal to # of cores? Or something much =
higher?<br>
<br>
<br>
</div></div>The only use case I think think of for the remap threads featur=
e is if you have a plugin that can block a thread. With block, I mean, not =
yield it in some reasonable amount of milliseconds. For now, if you use thi=
s remap threads processor, you also have to turn off the per thread sharing=
 of sessions, and switch to a single global session pool.<br>

<span class=3D"HOEnZb"></span></blockquote><div><br><br></div><div>Ok, so i=
t sounds like if something isn&#39;t blocking, then there&#39;s no need to =
set it at all then. My Lua code is just doing some munging on the original =
destination IP, so should never block. Sound right? <br>
</div></div></div></div>

--089e013c68e281e5db04ebd2ddd3--