1. При такой настройке ВСЕГДА часть клиентов пойдёт на ns1 , а часть на ns2. Мы только получим, что клиенты будут "раскидываться" по разным серверам, а в случаях проблем с одним сервером, чать клиентов будет получать ошибку.
В случае микроскопического TTL для зоны клиенты будут постоянно дергать ДНС, и получать ответ от работающего именно сейчас сервера.
Впрочем, это не спасет от кривонастроенных кэшей.
2. Две разные зоны держать на двух dns-серверах одного домена вам вряд ли даст регистратор.
DJ_AlieN: вы действительно верите что один запрос из таблицы в 180 мегабайт напичканной индексами и кешированием запросов может исполняться более 5 часов на восьмиядерном ксеоне?
netwind: Более того, если сделать tcpdump не на лупбеке, эти пакеты вообще не видно. Пакеты даже виртуально никуда не отсылаются. Может быть разницы между лупбеком и локальным IP нет совсем в смысле расхода сокетов в состоянии TIME_WAIT.
"Эти пакеты" - это какие?
На самом деле, ничего архикриминального в tw-сокетах нету. Ну, кроме того, что оно забивает таблицу дескрипторов и поиск по ней работает дольше. Впрочем, если 1-2ms для вас роли не играет - то можно вообще забить.
При очень некоторых условиях (кривонастроенная система, большое количество запросов) потенциально есть риск упереться в недостаток сокетов на интерфейсе - в случае лупбэка достаточно сделать еще один лупбэк, и поехать дальше.
netwind: Outsourcenow, тогда почему на bsd их нет ? правильный процесс завершения вообще ведь не имеет смысла при локальных соединениях. и еще номера портов там продолжают расти, но на другом сервере нет.
Потому что у бсд сетевая подсистема написана прямыми руками :-)
Если серьезно - ну, вот так тут заведено. У бсд есть ручка, который выставляется таймаут на time_wait, у линукса - нет. У бсд есть nolocaltimewait - у линукса, как оказывается, нет.
Я предполагаю, что есть некая ручка, отвечающая за политику выбора нового сокета. В линуксе reuse используется, только когда нету свободных сокетов, а в бсд, похоже, наоборот - новый сокет создается только когда реюзать нечего. Не знаю точно, надо в код
смотреть.
Но вобщем, вот это вот все - одна из причин, почему идеологически верно держать бэкэнд/fastcgi-сервер на лупбэке.
myhand: "звучит умно" (с)
что вы хотели этим сказать, если не сложно?
Зачем блочить поток, работающий с клиентом?
многие точно также используют апач. тем более, что там давно уже есть
mod_dbd, использовать который в своем модуле никто не мешает.
Ну круто. Только почему действительно крупные игроки на рынке все как один переезжают на nginx?
nginx просто моден, ну какие приемущества дает его модель
работы в качестве бакенда?
Гибкость и нетребовательность к ресурсам. Ну плюс, очень удобная интеграция самодельных функций в парсер URI и обработку переменных.
ну и что мешает использовать тот самый апач в качестве демона? он ведь
конструктор по сути. только большинство работы за нас уже
сделали (mpm, модули для работы с БД ...)
Зачем? Ну вот зачем тащить весь этот ворох апачевого мусора, со всякими оверрайдами в систему, задача которой - принять запрос от клиента, и спихнуть в обработчик динамики?
Впрочем, ладно - я прекрасно понимаю, что истинное мнение хрен оспоришь. Нравится вам апач - пользуйтесь апачем :) У меня его уже года три как нету нигде, и слава богу.
много их и не будет)
так как такое зделать? а то вы только канал считаете и сколько людей)))))
Так вам уже написали - на сервер shoutcast / icecast, клиентам - любой плеер, умеющий отдавать поток. winamp как вариант.
Вообшем появилась надобность зделать онлайн радио что бы было некое количесво удаленных DJ'eв.
10 мбит - мало. Это только на поиграться.
1. При такой настройке ВСЕГДА часть клиентов пойдёт на ns1 , а часть на ns2. Мы только получим, что клиенты будут "раскидываться" по разным серверам, а в случаях проблем с одним сервером, чать клиентов будет получать ошибку.
В случае микроскопического TTL для зоны клиенты будут постоянно дергать ДНС, и получать ответ от работающего именно сейчас сервера.
Впрочем, это не спасет от кривонастроенных кэшей.
2. Две разные зоны держать на двух dns-серверах одного домена вам вряд ли даст регистратор.
Да кто его спросит-то? :-)
вы действительно верите что один запрос из таблицы в 180 мегабайт напичканной индексами и кешированием запросов может исполняться более 5 часов на восьмиядерном ксеоне?
А что мешает? :-)
А как надо правильно? и что Вы скажите насчет самой ошибки?
listen 12.13.14.15:80;
ну или куда у вас там домен резолвится.
Что касается ошибки - то там все написано, у вас домен не резолвится, во всяком случае, снаружи.
Доброго времени суток.
Никогда! НИКОГДА!!! не надо делать listen на fqdn. _Только_ на ip-адрес.
Сабж, правлю /etc/php.ini, необходимо внести пару строк, сохранить и выйти
М-м-м-м-м... Ну я не знаю, конечно, как пацаны - но вот у меня лично возражений нет, делайте.
Более того, если сделать tcpdump не на лупбеке, эти пакеты вообще не видно. Пакеты даже виртуально никуда не отсылаются. Может быть разницы между лупбеком и локальным IP нет совсем в смысле расхода сокетов в состоянии TIME_WAIT.
"Эти пакеты" - это какие?
На самом деле, ничего архикриминального в tw-сокетах нету. Ну, кроме того, что оно забивает таблицу дескрипторов и поиск по ней работает дольше. Впрочем, если 1-2ms для вас роли не играет - то можно вообще забить.
При очень некоторых условиях (кривонастроенная система, большое количество запросов) потенциально есть риск упереться в недостаток сокетов на интерфейсе - в случае лупбэка достаточно сделать еще один лупбэк, и поехать дальше.
Outsourcenow, тогда почему на bsd их нет ? правильный процесс завершения вообще ведь не имеет смысла при локальных соединениях. и еще номера портов там продолжают расти, но на другом сервере нет.
Потому что у бсд сетевая подсистема написана прямыми руками :-)
Если серьезно - ну, вот так тут заведено. У бсд есть ручка, который выставляется таймаут на time_wait, у линукса - нет. У бсд есть nolocaltimewait - у линукса, как оказывается, нет.
Я предполагаю, что есть некая ручка, отвечающая за политику выбора нового сокета. В линуксе reuse используется, только когда нету свободных сокетов, а в бсд, похоже, наоборот - новый сокет создается только когда реюзать нечего. Не знаю точно, надо в код
смотреть.
Но вобщем, вот это вот все - одна из причин, почему идеологически верно держать бэкэнд/fastcgi-сервер на лупбэке.
"звучит умно" (с)
что вы хотели этим сказать, если не сложно?
Зачем блочить поток, работающий с клиентом?
многие точно также используют апач. тем более, что там давно уже есть
mod_dbd, использовать который в своем модуле никто не мешает.
Ну круто. Только почему действительно крупные игроки на рынке все как один переезжают на nginx?
nginx просто моден, ну какие приемущества дает его модель
работы в качестве бакенда?
Гибкость и нетребовательность к ресурсам. Ну плюс, очень удобная интеграция самодельных функций в парсер URI и обработку переменных.
ну и что мешает использовать тот самый апач в качестве демона? он ведь
конструктор по сути. только большинство работы за нас уже
сделали (mpm, модули для работы с БД ...)
Зачем? Ну вот зачем тащить весь этот ворох апачевого мусора, со всякими оверрайдами в систему, задача которой - принять запрос от клиента, и спихнуть в обработчик динамики?
Впрочем, ладно - я прекрасно понимаю, что истинное мнение хрен оспоришь. Нравится вам апач - пользуйтесь апачем :) У меня его уже года три как нету нигде, и слава богу.