httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bannister <>
Subject Re: The Case for a Universal Web Server Load Value
Date Thu, 15 Nov 2012 10:00:37 GMT
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-user but rather just find another
available server or hold on to the request until one becomes available (or some timeout value
is met if things are that bad).
>> This only makes sense for idempotent requests. What about a POST or PUT?
> What's the problem?  LB will get the request, send OPTIONS * to the backends to find
an available one and only then push the POST/PUT back to it...

Sorry; I was trying to be brief but that meant skipping some details.

We have to assume that at some point we have uneven loading and that there is a backend with
spare capacity (otherwise, yeah, no loadbalancer will help). A backend that started off responsive
may slow down due to load but still be able to keep the TCP connection alive. With GET, we
can just chuck requests at the backends and only decide what to do when a request goes bad
or the response is late. GET's idempotency means we can retry the same request with a different
backend. This strategy doesn't work with POST etc.

Uneven load could arise through imperfect balancing by a reverse proxy, or it could be exogenous
– maybe one of the backends has fired off an expensive scheduled task?

PS. If we are doing load skewing or otherwise managing the number of active backends, we definitely
want a way to learn the load on each backend. A bit of standardisation would be nice here
(de facto or otherwise). Apache httpd is a good place to start off, because of its market
share, even if this goes beyond the scope of httpd itself.

Tim Bannister –

View raw message