Re: Plan to add sandbox branch

2018-11-27 Thread Daniel Ruggeri
Hi, Jim;
   I'm coming up empty on a search against the Google-machine for SURVEY 
protocol. Any pointers you can share?

   I'm also curious what your thoughts are about dealing with growth of the 
worker pool beyond the control of the proxy admin. For example, if I configure 
a balancer for 10 nodes, I have an idea of tuning parameters I might set 
differently than if the number of backends is in the tens of servers.
-- 
Daniel Ruggeri

On November 27, 2018 5:23:25 AM CST, Jim Jagielski  wrote:
>In the coming week or so, I will be committing my load balance,
>load determination and discovery work to a sandbox trunk. Many
>people have asked for more info, so here we go.
>
>Basically, this new feature uses nanomsg (nng) to implement the
>SURVEY protocol between workers (nodes) and the front end server.
>The proxy server will send out MEMBERSHIP and STATUS surveys, that
>nodes can respond to; thus new nodes can automagically add themselves
>as they come up as well as remove themselves when they restart or
>shutdown via MEMBERSHIP. STATUS can be used to provide real-time
>load on each node, which will be sent via a __packed__ struct,
>ala NTP and other common usage patterns, in which 32bit fields are
>converted from endian-ness to network and back. That STATUS info can
>be used for "intelligent" load balancing and will provide some
>typical server metrics such as memory, # of cpus, etc...


Plan to add sandbox branch

2018-11-27 Thread Jim Jagielski
In the coming week or so, I will be committing my load balance,
load determination and discovery work to a sandbox trunk. Many
people have asked for more info, so here we go.

Basically, this new feature uses nanomsg (nng) to implement the
SURVEY protocol between workers (nodes) and the front end server.
The proxy server will send out MEMBERSHIP and STATUS surveys, that
nodes can respond to; thus new nodes can automagically add themselves
as they come up as well as remove themselves when they restart or
shutdown via MEMBERSHIP. STATUS can be used to provide real-time
load on each node, which will be sent via a __packed__ struct,
ala NTP and other common usage patterns, in which 32bit fields are
converted from endian-ness to network and back. That STATUS info can
be used for "intelligent" load balancing and will provide some
typical server metrics such as memory, # of cpus, etc...