>> That's more of an issue with the site than a (proxy based) load >> balancer - the LB would be doing the exact same thing as the client.
WT> Precisely not and that's the problem. The proxy cannot ask the user WT> if he wants to retry on sensible requests, and the cannot precisely WT> know what is at risk and what is not. The client knows a lot more about WT> that. For instance, I think that the client will not necessarily repost WT> a GET form without asking the user, but it might automatically report a WT> request for an image. I can see a small confusion here because I've used the wrong terminology. Proxy is not the correct term, as there are actual proxy devices out there (eg: Squid) which are generally visible to the client/server and shouldn't be intentionally resending requests upon failure. To describe what I mean is that the loadbalancer would keep a copy (silently) of the client's request until a server gave a valid response. So should the connection drop unexpectedly with server "A" after the request, the load balancer would assume something went wrong with that server, and then resend the request to Server "B". Throughout this, the end client would have only sent 1 request to the loadbalancer (as it sees the LB as the "end server"). Obviously this also allowed the loadbalancer to manipulate the headers and route requests as required. >> WT> So probably that a reasonable balance can be found but it is >> WT> clear that from time to time a user will get an error. >> >> That sounds like the mantra of the internet in general. :-) WT> I don't 100% agree. Sorry, I meant out of the context of this conversation - there's many many times that your statement has had context within other conversations about internet connectivity in general and admin's views on it (usually ending up with "it's good enough" - Especially with DPI manipulated telco connectivity). WT> Oh I precisely see how it works, it has several names from vendor to vendor, WT> often they call it "connection pooling". Doing a naive implementation is not WT> hard at all if you don't want to care about errors. The problems start when WT> you want to add the expected reliability in the process... I will mention the vendor's software we used has since then been completely re-written from ground up, probably to cover some of those issues and get much better performance at higher speeds. WT> In practice, instead of doing an expensive copy, I think that 1) configuring WT> a maximum number of times a connection can be used, 2) configuring the maximum WT> duration of a connection and 3) configuring a small idle timeout on a connection WT> can prevent most of the issues. Then we could also tag some requests "at risk" WT> and other ones "riskless" and have an option for always renewing a connection WT> on risked requests. In practice on a web site, most of the requests are images WT> and a few ones are transactions. You can already lower the load by keeping 95% WT> of the requests on keep-alive connections. That does sound very logical. WT> I believe you that it worked fine. But my concern is not to confirm WT> after some tests that finally it works fine, but rather to design it WT> so that it works fine. Unfortunately HTTP doesn't permit it, so there WT> are tradeoffs to make, and that causes me a real problem you see. Yes, the more I re-read the rfc, the more I feel your pain when they specify "SHOULD/MAY" rather than "MUST/MUST NOT" allowing for those corner cases to occur in the first place. WT> Indeed. Not to mention that applications today use more and more resources WT> because they're written by stacking up piles of crap and sometimes the WT> network has absolutely no impact at all due to the amount of crap being WT> executed during a request. I don't want to get started in the [non-]quality of the asp programmer's code of that project. I still have nightmares. Cheers, Ross. --
