httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: The Case for a Universal Web Server Load Value
Date Wed, 14 Nov 2012 23:32:41 GMT
On 15 Nov 2012, at 12:48 AM, Tim Bannister <isoma@jellybaby.net> 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 might use POST, either
because they are too long for GET or because the query is an update.
> 
> The reverse proxy / balancer manager might want to:
> • balance query workload across the active set of webservers
> • spin up an extra backend as required by load
> • skew load onto the minimum number of webservers (and suspend any spares)
> 
> SPARQL is an example of a varying workload where none of httpd's existing lbmethods is
perfect. One complex query can punish a backend whilst its peers are idle handling multiple
concurrent requests. SPARQL sometimes means POST requests; a subset of these are safely repeatable
but determining which ones is too complex for any HTTP proxy.

There is no reason why a load balancer can't take into account existing requests in addition
to new requests when making load balancing decisions. When there are a number of connections
to a backend that are in flight but taking a while to complete, this is a sign the backend
may be busy and should be avoided.

That said if you have pathologically expensive requests coming into your backends, no load
balancer is going to help you.

Regards,
Graham
--


Mime
View raw message