Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Redundant Web servers




On Mon, 14 Dec 2009, Tom Metro wrote:

> Daniel Feenberg wrote:
>> ...5 minutes (our DNS TTL)...
>> 
>> On our web site all internal links are relative. This means that once a 
>> browser session finds a working server, it will stay with that server - so 
>> there is only one delay per visitor. If the links were absolute, then there 
>> would be a delay on 50% of page views, not very attractive.
>
> If the browser and OS honor your TTL in their DNS cache, and the browser is 
> either not using keep alive or the keep alive connection has timed out, I 
> would expect the next page retrieval after a 5+ minute delay will trigger 
> another DNS lookup, and potentially another connection timeout. If the site 
> has lengthly content that takes time to read, such a delay may not be 
> unusual.

Not sure what you mean by "read"? We do have some pages so large they take 
more than 5 minutes to deliver, but I am surprised to learn that a browser 
would switch IPs in the middle of a page read.

Taking your information into consideration I am now inclined to use the 
rrset statement in Bind to specify that IP addresses be offered in a fixed 
order.  The primary server would always be offered first, and the second 
address would be there only in case the first timed out. Then this problem 
would be restricted to times when the primary server was down - and the 
alternative would be no service at all. We have little need for load 
balancing - the webserver can deliver more throughput than our internet 
link can handle.

Thanks
Dan Feenberg








BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org