Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On Fri, Nov 08, 2002 at 05:28:25PM -0500, John Abreau wrote: > The thng about nameservers is that *everything* depends heavily > on them. The nameservers are the biggest factor affecting your > perceived response time for every interactive use you make of the > Internet. Sorry, that's not so. In certain cases, name response is a significant factor, but it hardly ever dominates wall-clock response time. Let's look at some typical cases: - ssh session: initial setup includes two DNS lookups, but total session time is in minutes, and interactive response time is extremely similar to single-packet round trip time on unloaded CPUs. On heavily loaded CPUs, CPU time dominates. - file transfer: initial setup includes one, possibly two DNS lookups, but even a 1MB file over an uncongested cable modem link takes on the order of 8 seconds. Larger files or slower links decrease DNS's contribution. Doesn't really matter whether this is streaming or prerecorded. - remote desktop control: again, no DNS lookups after the session is established, and sessions vastly outlast setup. - any non-netcentric application, used remotely: just like a remote desktop control scenario. - web surfing: here's the first case where DNS resolution time looks like it might be a factor, and in fact it is. Each page loaded requires a minimum of one DNS lookup, and often several: text from one server, graphics from another, advertising from two more, and database lookups from a sixth. However, every modern browser has a built-in DNS cache to alleviate such problems, so subsequent requests to the same servers do not incur that penalty. Still, having a local DNS cache is almost always a win, just not a particularly huge one. There's no reason not to have nearly every desktop, and certainly every small network, so equipped. -dsr-
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |