On 12 Nov 2012, at 15:04, Jim Jagielski wrote: > Booting the discussion: > > > http://www.jimjag.com/imo/index.php?/archives/248-The-Case-for-a-Universal-Web-Server-Load-Value.html
There's bound to be more than one way to do it :-) I'm afraid I don't favour providing status data in every response. Doing it that way means that the reverse proxy has to filter something out and it isn't really clean HTTP. Would a strict implementation need to throw in a Vary: * as well? Instead, I would rather have load information provided via something broadly RESTful. httpd already has server-status and a machine readable variant, but there's room to improve it. I'd start with offering status via JSON and / or XML. I'd prefer XML because of the designed-in extensibility. With this approach, peers that want frequent server-status updates can request this status as often as they like, and can use the usual HTTP performance tweaks such as keepalive. A load-balancing reverse proxy can read this information, or a separate tool can track it and update the load balancer's weightings. As for how to express load? How about a float where 0.0 represents idle and 1.0 represents running flat out. A trivial implementation for Unix would take the load average and divide it by the number of CPUs. I would keep all of this separate from whether or not the backend has outright failed. Perlbal, and maybe some other software, will check an HTTP connection via an initial “OPTIONS *”, and will of course remember when a connection goes bad either via a TCP close or a 5xx response. -- Tim Bannister – is...@jellybaby.net
smime.p7s
Description: S/MIME cryptographic signature
