Я искал информацию об использовании Google DNS для нашего веб-сайта, но нашел информацию об использовании Google Public DNS для наших локальных компьютеров.
Кто-нибудь знает, насколько это быстрее? Или хороший способ это измерить?
http://code.google.com/p/namebench/
Он сравнит несколько общедоступных DNS-серверов, включая Google, с вашим текущим.
Есть также Тест GRC DNS. Хотя похоже, что это только Windows (веб-страница утверждает, что Linux / WINE работает).
Использование Google DNS (или OpenDNS) может иметь негативные последствия для некоторых интернет-провайдеров, когда вы используете службы (например, iTunes или YouTube), которые используют сети CDN, такие как Akamai, для распространения контента.
Насколько я понимаю, сети CDN будут платить за одноранговое соединение или совместное размещение с сетями Интернет-провайдера и направлять трафик из сети Интернет-провайдера в CDN через темное оптоволоконное соединение, тем самым избегая перегрузки Интернета и повышая производительность. В Сеть передачи данных AOL является примером такой услуги для абонентов кабельного телевидения Road Runner.
ИМО, использование Google DNS имеет смысл только в следующих сценариях:
Для меня филиал Time Warner в северной части штата Нью-Йорк управляет довольно хорошей сетью, поэтому я использую DNS провайдера. Я думаю, что ISP DNS в любом случае улучшится, поскольку компьютеры становятся намного быстрее, а старые дрянные ящики, которые обычно выполняли служебные функции, такие как обслуживание DNS, поглощаются кластерами VMWare.
Вот сравнение использования Google DNS и ISP DNS для видео на YouTube:
Google DNS
$ ping v16.lscache2.c.youtube.com
PING v16.lscache2.l.google.com (209.85.239.38): 56 data bytes
64 bytes from 209.85.239.38: icmp_seq=0 ttl=47 time=54.822 ms
64 bytes from 209.85.239.38: icmp_seq=1 ttl=47 time=59.130 ms
64 bytes from 209.85.239.38: icmp_seq=2 ttl=47 time=56.981 ms
...
64 bytes from 209.85.239.38: icmp_seq=30 ttl=47 time=64.127 ms
^C
--- 209.85.239.38 ping statistics ---
31 packets transmitted, 31 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 53.596/69.145/104.663/13.599 ms
Интернет-провайдер DNS
$ ping v16.lscache2.c.youtube.com
PING v16.lscache2.l.google.com (74.125.0.38): 56 data bytes
64 bytes from 74.125.0.38: icmp_seq=0 ttl=54 time=37.129 ms
64 bytes from 74.125.0.38: icmp_seq=1 ttl=54 time=26.411 ms
64 bytes from 74.125.0.38: icmp_seq=2 ttl=54 time=21.199 ms
...
64 bytes from 74.125.0.38: icmp_seq=29 ttl=54 time=25.591 ms
64 bytes from 74.125.0.38: icmp_seq=30 ttl=54 time=20.021 ms
^C
--- v16.lscache2.l.google.com ping statistics ---
31 packets transmitted, 31 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 18.686/24.215/37.129/4.080 ms
ВАЖНОЕ ПРИМЕЧАНИЕ. Это ни в коем случае не является научным тестом - другие явления могут быть ответственны за другой результат DNS.
Google Public DNS (8.8.8.8 или 8.8.4.4) дает относительно стабильное время ответа. Используя утилиту dig, вы можете убедиться в этом сами, набрав:
dig @8.8.8.8 www.serverfault.com
В итоге вы получите что-то вроде этого:
;; Query time: 67 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Feb 19 09:07:15 2010
;; MSG SIZE rcvd: 246
Повторный запуск команды dig с помощью dig, вероятно, немного ускорит ответ:
;; Query time: 37 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Feb 19 09:07:15 2010
;; MSG SIZE rcvd: 246
Это связано с тем, что большинство DNS-серверов кэшируют поиск сервера, который он использует для поиска вне себя. Популярные сайты, вероятно, уже будут в кеше. Последующие запросы происходят из кеша и повышают производительность.
При использовании общедоступного DNS Google разница между полным поиском и кешированным поиском не так уж велика. Однако, если у вас есть собственный (менее загруженный) кэширующий DNS-сервер, вы можете увидеть существенные различия.
Если вы выполните поиск сайта, которого нет в вашем кэше, вы можете увидеть начальное время запроса в несколько сотен миллисекунд. Однако, как только он окажется в кеше, время поиска, вероятно, будет близко к нулю (0) миллисекунд.
Первоначальный запрос:
dig @Your.DNS.Server.IP www.serverfault.com
Что в итоге дает следующий результат:
;; Query time: 184 msec
;; SERVER: Your.DNS.Server.IP#x53(Your.DNS.Server.IP)
;; WHEN: Fri Feb 19 09:14:19 2010
;; MSG SIZE rcvd: 217
Последующий запрос:
dig @Your.DNS.Server.IP www.serverfault.com
Что в итоге дает следующий результат:
;; Query time: 0 msec
;; SERVER: Your.DNS.Server.IP#x53(Your.DNS.Server.IP)
;; WHEN: Fri Feb 19 09:14:19 2010
;; MSG SIZE rcvd: 217
Это близкое к нулю (если не нулевое) время запроса будет длиться до тех пор, пока поиск www.serverfault.com не устареет из кеша разрешения имен вашего локального DNS-сервера.
Эти числа могут со временем увеличиваться. Первоначальный поиск адреса в вашем DNS, вероятно, будет намного дольше, чем первоначальный поиск в Google Public DNS. Однако последующие поиски (пока они остаются в кеше), вероятно, будут значительно быстрее. С другой стороны, Google Public DNS постоянно находится в диапазоне от 30 до 60 миллисекунд (с нашего местоположения, в ненаучных тестах).
Вам придется взвесить все за и против.
Забавно, но пока я тестировал это, я не мог связаться с общедоступными DNS-серверами Google из моей сети. Я не знаю почему, и я изучаю это. К счастью, мы используем наши собственные серверы и не можем эффективно отключиться от сети. Если бы я был в этом месте и полагался только на общедоступный DNS-сервер Google, у меня были бы серьезные проблемы с подключением до тех пор, пока проблема не будет решена. Итак, взвесьте и эту внешнюю зависимость.