On 15 Nov 2012, at 12:48 AM, Tim Bannister <is...@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 --
smime.p7s
Description: S/MIME cryptographic signature
