httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bannister <is...@jellybaby.net>
Subject Re: The Case for a Universal Web Server Load Value
Date Wed, 14 Nov 2012 22:48:43 GMT
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 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?


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.

-- 
Tim Bannister – isoma@jellybaby.net


Mime
View raw message