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 Tue, 13 Nov 2012 08:58:41 GMT
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 – isoma@jellybaby.net


Mime
View raw message