httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Sutherland <ja...@cam.ac.uk>
Subject Re: Zues' new Load Balancer (was Re: ILOVEYOU)
Date Fri, 05 May 2000 06:11:58 GMT
On Thu, 4 May 2000, Jeffrey W. Baker wrote:

> On Thu, 4 May 2000, James Sutherland wrote:
> 
> > Finally, just to come completely back ON-topic: Has anyone here noticed
> > Zeus's new product, Load Balancer? More interestingly, has anyone compared
> > it with what I was suggesting a few weeks ago?
> 
> I wasn't able to find your message of a few weeks ago, but I have looked
> at the Load Balancer product.  I didn't give it a realy good evaluation
> because 1) you can't download and use an evaluation copy and 2) their
> website is totally lacking in technical details.  They do not make any
> claims of packet forwarding rates, byte-forwarding rates, nor packet
> forwarding latency.  Even numbers from a single platform would give a good
> ballpark figure.

In terms of statistics, it is more or less bare. However, there is enough
there to understand the overall organisation: clients connect to the
front-end boxes, which then distribute the connections to the backend
boxes according to URL and backend load levels.

> What information is on their website is mostly meaningless.  They don't
> explain what technology they use to achieve takeover by the hot standby
> machine in case of failure. 

There isn't a hot standby machine, which would explain that :-)

It uses a pair of machines, both serving requests simultaneously. A simple
round robin would achieve this (although they may well use some IP
takeover system as well).

> I assume arp tricks, but who knows.  They say they support HTTP/1.1
> features and SSL, with the SSL load balanced across the backend.  I
> don't see how they could do both of those things at once, but they
> don't mention the conflict. 

I don't see one. They DO point out that the HTTP/1.1 handling is for HTTP
sessions (non-SSL); for SSL, it just byte forwards, with (I think) some
logic to try to keep sessions with the same backend box that handled them
the last time.

> They also point out their support for chunked encoding and byte
> ranges, but I can't imagine how this amounts to anything more than
> straight packet forwarding until the connection closes.

It's not packet forwarding; it's basically an HTTP/1.1 enabled mod_proxy,
with SSL support.

> For the money they want, they are competing against ASIC-based packet
> routing technology.  The hardware load balancers can forward packets at
> rates of 100,000 packets/sec, with latencies <10 microseconds.  Their
> decision engines are pretty quick, too, although I don't have hard numbers
> on them.

I agree; for an expensive, proprietary system, this doesn't seem very
desirable. However, a free open source one could be more attractive...


James.


Mime
View raw message