[ale] forwarded message from Mail Delivery Subsystem

Eric eric at uxeric.compgen.com
Mon Mar 25 16:43:37 EST 1996


My theory is that HTTPD server load is mainly caused by the number of
processes forked on a machine to handle requests plus any 
processing done by cgi scripts.  One could imagine an
architecture of web servers where a master server acted mainly as a
gateway and load balancing.

  
                                              +-  slave server 0
                                              |-  slave server 1
INET --> external interface ---> master server+-  slave server 2
					      |-  ...
                                              +-  slave server N

The master server would be the machine 'www.foo.com'.  It would simply
forward all requests to one of the slave servers.  The slave server
would process the request and forward the output back through the master
server out the external interface.  The communication between slave and
master would not have to be torn down and rebuilt each time and would
provide information to the master necessary for the master to properly
balance load.  Presumably the master and slaves are on a fast LAN and
the OS on the master server can keep up with many concurrent TCP
connections.

The master  would be kept busy forwarding packets and accepting new
connections.  The slaves would be busy reading, writing and executing
cgi programs.


Another theory for making a fast web server would be to modify the OS,
so that the slaves 'spoof' TCP connections from the master.  The master
would recieve a connection and select a slave server to handle the load.
The master would then communicate with the selected slave server, pass
the parameters necessary for the slave to 'spoof' as the master server,
and build the reply connections.  This eliminates the need for the 
master to forward the reply from the slave.  The slave servers all
pretend to be the external interface on replies.    


Let's go implement this with Linux and make a few million dollars.

- -Eric.

Jeff Barber writes:
 > Dan Newcombe writes:
 > > 
 > > > I spoke with a rep from SGI that mentioned you could take SGI WebForce 
 > > > servers and link them together to handle the incoming load.
 > > > Is there a way you can do that with Linux boxes or is this guy blowing
 > > > smoke?
 > > > He said that Netscape has 8 SGI's linked together at www.netscape.com and 
 > > > that's how they handled 1 Billion hits last month on their site.
 > > 
 > > Yahoo does something like that - you hit www.yahoo.com, and you may be 
 > > sent to www1, www2, www3, etc...
 > > 
 > > It may be some kinda proxy server, or special DNS setup which gives a 
 > > different address each time to keep them rotating.  The main concern 
 > > would be how do you let all 8 share data?  Do they all have copies of 
 > > the same data on thier machines?  Or are they linked via a fast 
 > > ethernet internally, with external connections on another net segment?
 > 
 > I understand that some sites do this with DNS as you describe, but that
 > this can cause problems when DNS lookups get cached.  That is, if you
 > ask your local DNS server machine to lookup www.yahoo.com and get www3's
 > IP address, chances are good that your neighbor is going to get the same
 > address when doing the same lookup.  Of course, that still serves to
 > distribute the load somewhat, but if a single site is acting as a caching
 > server for a large subnet, it can lead to overloads on particular machines.
 > 
 > According to Netscape, they actually have a special hack in their browser
 > that adds a digit to the host name *before* doing the DNS lookup to the
 > Netscape domain (I don't know the algorithm for what digit to add) -- thus
 > ensuring a fairly uniform spread across the server pool.  Unfortunately,
 > your average web site doesn't have that luxury.
 > 
 > BTW, according to Netscape folks at their recent developer conference,
 > they have other machines than SGIs in their pool of servers, including
 > Suns, HPs, DEC Alphas, etc.  (I guess you wouldn't expect to hear that
 > from an SGI rep though, eh? :-)
 > 
 > 
 > -- Jeff






More information about the Ale mailing list