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 – [email protected]
smime.p7s
Description: S/MIME cryptographic signature
