On Nov 14, 2012, at 5:19 PM, Ask Bjørn Hansen wrote:
>
> On Nov 14, 2012, at 11:01, Tim Bannister wrote:
>
>>> I really like how Perlbal does it:
>>>
>>> It opens a connection when it thinks it needs more and issues a (by
>>> default, it's configurable) "OPTIONS *" request and only after ge
On 15 Nov 2012, at 07:01, Issac Goldstand wrote:
> On 15/11/2012 00:48, Tim Bannister wrote:
>> On 14 Nov 2012, at 22:19, Ask Bjørn Hansen wrote:
>>> The backend should/can know if it can take more requests. When it can't it
>>> shouldn't and the load balancer shouldn't pass that back to the end-
On 15/11/2012 00:48, Tim Bannister wrote:
On 14 Nov 2012, at 22:19, Ask Bjørn Hansen wrote:
I know I am fighting the tide here, but it's really the wrong smarts to put in
the load balancer.
The backend should/can know if it can take more requests. When it can't it
shouldn't and the load bal
On 15 Nov 2012, at 12:48 AM, Tim Bannister wrote:
> This only makes sense for idempotent requests. What about a POST or PUT?
>
>
> For a plausible example that mixes POST and GET: a cluster of N webservers
> providing SPARQL HTTP access to a triplestore. Most queries will use GET but
> some m
On 14 Nov 2012, at 22:19, Ask Bjørn Hansen wrote:
> I know I am fighting the tide here, but it's really the wrong smarts to put
> in the load balancer.
>
> The backend should/can know if it can take more requests. When it can't it
> shouldn't and the load balancer shouldn't pass that back to t
On Nov 14, 2012, at 11:01, Tim Bannister wrote:
>> I really like how Perlbal does it:
>>
>> It opens a connection when it thinks it needs more and issues a (by default,
>> it's configurable) "OPTIONS *" request and only after getting a successful
>> response to the test will it send real requ
On 14 Nov 2012, at 18:49, Ask Bjørn Hansen wrote:
> I really like how Perlbal does it:
>
> It opens a connection when it thinks it needs more and issues a (by default,
> it's configurable) "OPTIONS *" request and only after getting a successful
> response to the test will it send real requests
I really like how Perlbal does it:
It opens a connection when it thinks it needs more and issues a (by default,
it's configurable) "OPTIONS *" request and only after getting a successful
response to the test will it send real requests on that connection (and then it
will keep the connection ope
On Nov 13, 2012, at 5:58 AM, Nick Kew wrote:
> As to what that represents, that must surely depend on the bottlenecks
> in a particular system. A backend doing heavy number-crunching and
> one doing lots of complex SQL queries have different loads, and a
> good load measure for one may be meani
That's the idea...
On Nov 13, 2012, at 7:05 AM, Graham Leggett wrote:
> On 13 Nov 2012, at 1:20 PM, Nick Kew wrote:
>
>>> As to the format of the header,
>>
>> If Jim's thinking Universal, then the forum for discussion at
>> that level of detail isn't going to be this list! Head over to IETF
On 13 Nov 2012, at 1:20 PM, Nick Kew wrote:
>> As to the format of the header,
>
> If Jim's thinking Universal, then the forum for discussion at
> that level of detail isn't going to be this list! Head over to IETF ….
I would love that such a thing ended up at the IETF, but it needs to start
On 13 Nov 2012, at 11:17, Graham Leggett wrote:
> As to the format of the header,
If Jim's thinking Universal, then the forum for discussion at
that level of detail isn't going to be this list! Head over to IETF
--
Nick Kew
On 12 Nov 2012, at 5:04 PM, Jim Jagielski wrote:
>
> http://www.jimjag.com/imo/index.php?/archives/248-The-Case-for-a-Universal-Web-Server-Load-Value.html
+1 to the idea of a header, it is simple and unobtrusive, and doesn't give you
any security headaches that any out-of-band header would g
A protocol for backends to communicate load to balancers in real time
has appeal. You could hack it in HTTP or similar with
X-Server-Load: 0.1234
Perhaps a series of numbers representing different moving averages, etc.
As to what that represents, that must surely depend on the bottlenecks
in a pa
On 12 Nov 2012, at 15:04, Jim Jagielski wrote:
> Booting the discussion:
>
>
> http://www.jimjag.com/imo/index.php?/archives/248-The-Case-for-a-Universal-Web-Server-Load-Value.html
There's bound to be more than one way to do it :-)
I'm afraid I don't favour providing status data in every re
You say:
"""I have traditional Unix-type load-average and the percentage of how
"idle" and "busy" the web-server is. But is that enough info? Or is that
too much? How much data should the front-end want or need? Maybe a single
agreed-upon value (ala "load average") is best... maybe not. These are
Booting the discussion:
http://www.jimjag.com/imo/index.php?/archives/248-The-Case-for-a-Universal-Web-Server-Load-Value.html
17 matches
Mail list logo
