Curious about proxy.config.remap.num_remap_threads

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Curious about proxy.config.remap.num_remap_threads

Mark Moseley
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?
Reply | Threaded
Open this post in threaded view
|

Re: Curious about proxy.config.remap.num_remap_threads

Leif Hedstrom

On Nov 22, 2013, at 11:18 AM, Mark Moseley <[hidden email]> 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.

— Leif

Reply | Threaded
Open this post in threaded view
|

Re: Curious about proxy.config.remap.num_remap_threads

Mark Moseley
On Fri, Nov 22, 2013 at 7:51 PM, Leif Hedstrom <[hidden email]> wrote:

On Nov 22, 2013, at 11:18 AM, Mark Moseley <[hidden email]> 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?
Reply | Threaded
Open this post in threaded view
|

Re: Curious about proxy.config.remap.num_remap_threads

Leif Hedstrom


On Nov 23, 2013, at 12:13 AM, Mark Moseley <[hidden email]> wrote:

On Fri, Nov 22, 2013 at 7:51 PM, Leif Hedstrom <[hidden email]> wrote:

On Nov 22, 2013, at 11:18 AM, Mark Moseley <[hidden email]> 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?

Right.

-- Leif