httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bannister <>
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:

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

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 –

View raw message