Comments 54
IMHO единственное адекватное объяснение этого феномена - кривые руки разработчиков BIND. Чем ещё можно объяснить разницу в скорости работы в несколько раз на разных OS в наше время?
а может быть дело в сборке?
Поясните, пожалуйста, что Вы имели в виду? Разные компиляторы?
ну наверно не ошибусь: всего :)
я вообще не вижу противоречий в результатах тестов
я вообще не вижу противоречий в результатах тестов
Вполне возможно. Разные компиляторы, разное окружение. Лично я не удивлен что Gentoo на первом месте, поскольку все собрано с поддержкой нативных инструкций именного той архитектуры и того проца, который стоит на тестируемой рабочей станции. А это не так мало как кажется и прирост может быть очень солидный. В случае с виндой, кхе кхе, мало того что все собрано грубо говоря под i386 так еще и особенности самой мастдайки... в частности управление памятью и своппинг.
UFO just landed and posted this here
djbdns научился прямо поддерживать ipv6 и SRV записи? Или view умеет? Что-то не припомню такого.
Честно говоря, я не в теме, т.к. ни IPv6 ни SRV-записи я не использую. Но я вижу, что пакет djbdns в моём Gentoo поддерживает USE-флаг ipv6, а в википедии на страничке с описанием SRV-записи есть пример для djbdns. Так что я пока не вижу описанных Вами проблем.
P.S. Что есть view и зачем он нужен - я не знаю, но предполагаю, что это одна из моря ненужных фич BIND, из-за которых он и является таким раздутым, глючным, тормознутым и дырявым. :)
P.S. Что есть view и зачем он нужен - я не знаю, но предполагаю, что это одна из моря ненужных фич BIND, из-за которых он и является таким раздутым, глючным, тормознутым и дырявым. :)
Нууу если не обращать внимания на то как там требуется их формировать... то да умеет.
View нужен когда надо изнутри отдавать одни ip а снаружи другие. Причем на одно и то же имя.
View нужен когда надо изнутри отдавать одни ip а снаружи другие. Причем на одно и то же имя.
В djbdns архитектурно на внутреннем интерфейсе висит один tinydns, а на внешнем другой. И у них запросто могут быть разные базы. Так что эта фича реализуется без проблем.
какие VIEW показывается определяется ACL а не тем где что висит.
А зачем вам такие сложности - не поясните ? Не пользую djbdns, но не вижу никаких проблем в этом подходе: повесьте два разных сервера на одной машине на разные IP и разнесите базы...
Это сложнее обслуживать. К тому же если у вас один и тот же IP обслуживает разные группы клиентов и должен отдавать разное, то VIEW это единственный выход.
Если придумать сложную и глупую задачу на свою задницу, то и функциональности BINDа не хватит. А для djbdns это решается поднятием алиаса на интерфейс со вторым IP и запуском ещё одного tinydns. Впрочем, такие задачи обычно не решаются, ибо не возникают. А когда возникают, это обычно означает кривую архитектуру сети, и решать их лучше не ACL-ами, а корректированием архитектуры сети.
Поясняю. Есть 2 ns сервера. Оба должны отдавать разные записи в одной зоне для разных IP-пространств. Причем эти IP-пространства могут быть вообще не ваши. В случае tinydns вы не сможете решить подобную задачу, потому что у вас нет VIEW.
Если эти IP-пространства не мои, и контролировать настройки DNS-сервера на этих машинах я не могу (т.е. не могу для них указать другой IP моего DNS-сервера - на котором запущен второй tinydns), то всё-равно задачу можно решить настроив файрвол на DNS-сервере так, чтобы он при обращении с этих IP на 53-й порт форвардил пакеты на другой мой локальный IP (или порт), на котором будет запущен второй tinydns с другой базой.
Восхитительно. SRV-записи вам понадобятся при интеграции BIND в Active directory, IPv6 понадобится уже в ближайшие 10 лет точно, а View - единственное красивое решение организации отдачи DNS-клиентам разных ресурсных записей в зависимости от того, откуда этот клиент приходит. Т.е. вещи в большинстве случаев все-таки использующиеся.
IPv6 потребуется уже в следующем году. В следующем году RIPE планирует прекратить выдачу адресов IPv4.
ссылочку можно?
Тфу прогнал. По прогнозам адресное пространство IPv4 закончится в 2009 году.
Тут почитайте http://www.potaroo.net/tools/ipv4/index.…
Тут почитайте http://www.potaroo.net/tools/ipv4/index.…
ну, такие прогнозы уже десять лет подряд каждый год случаются
Ну скажем так 10 лет назад это было давно и не правда. А тут адресов то уже мало осталось. И взять их можно только отъемом адресов. К тому же перевод части DNS ROOT серверов указывает на переход в IPv6
до того, как NAT перестал быть чудом космической техники, адресов, с точки зрения прогнозов, было еще меньше
То, что поддержка v6 на RS случилась совсем недавно является совершенно прекрасной иллюстрацией всех процессов, с этим в6 связанных. Типа, никто никуда не бежит
То, что поддержка v6 на RS случилась совсем недавно является совершенно прекрасной иллюстрацией всех процессов, с этим в6 связанных. Типа, никто никуда не бежит
Порою отъем - не такая уж плохая идея. Сейчас очень много дыр в адресном пространстве, вызванных наплевательским отношением владельцев.
Гм.. Странно, что Ubuntu не попал в ряды тестируемых дистрибутивов.
несмотря на его популярность на дескопах, на сервер его редко ставят
UFO just landed and posted this here
Начнём с того, что я очень сильно удивлюсь, если на корневых DNS-серверах используется BIND.
я сам удивился:
http://en.wikipedia.org/wiki/Root_namese…
http://en.wikipedia.org/wiki/Root_namese…
:) мир пересобирать на генте не так уж и обязательно на самом деле.
чаще чем дженту всяко... сурсбазед на хостинговом/днс-сервере - маразм.
интересно, почему?
:)
В крации - gcc на серваке потенциальная дыра.
В крации - gcc на серваке потенциальная дыра.
интересно, почему?
Ну как же, как же... принято считать, что если на сервере стоит gcc, то злобный хакер сможет скомпилировать там свой эксплойт. А если gcc не стоит, то хакер обломается. Вот такой миф, однако. Уж не знаю, почему считается что залить эксплойт бинарником это такая большая проблема...
Да чего - на хостингах железо хорошее - жента компилится быстро :)
А где Дебиан ?
аналогичный вопрос. И заодно где убунта. И вообще, тестирование никакое. Не указаны детали компиляции, версии системных библиотек и прочего. Частично эту инфу можно и самостоятельно собрать, но это долго и неинтересно.
ubuntu уж очень редко ставят на сервера.
а ещё дело в том что isc похоже выбирали решение для себя, а не задавались целью протестировать все что угодно. Об этом яркое заключение в исходной статье говорит =).
Дело в том, что ISC это разработчики BIND. И то, что "для себя" они взяли самую быструю систему (Gentoo), говорит о том, что:
- оптимизировать BIND они не собираются (ведь давно известно, что если нужно чтобы софтина работала шустро, нужно разработчику дать медленный комп - иначе у него стимула нет над производительностью работать :))
- разбираться почему на других системах BIND работает настолько медленнее и фиксить это они тоже не собираются
собственно встречный вопрос. Предположим была программа А. Работала примерно одинаково на AMD и на Intel. Потом взяли ребята и уменьшили в программе обращение к памяти и перемещение страниц раз в 10. Изза интегрированного контроллёра у АМД выигрыш получился 2%, а у Интел - 20%. А теперь вопрос, что у нас получилось:
"жутко не оптимизированная программулька под АМД (ну как - везде и всюду любят говорить "разработчики любят Интел явно больше и оптимизируют под него")"
Вопрос номер два - как тем же ребятам разогнать свою прогу на платформе АМД до тех высот до каких она разогналась под Интелом? А никак =).
И тут - учитывая разницу между разными версиями BSD глупо предполагать что они в этом не виноваты =).
"жутко не оптимизированная программулька под АМД (ну как - везде и всюду любят говорить "разработчики любят Интел явно больше и оптимизируют под него")"
Вопрос номер два - как тем же ребятам разогнать свою прогу на платформе АМД до тех высот до каких она разогналась под Интелом? А никак =).
И тут - учитывая разницу между разными версиями BSD глупо предполагать что они в этом не виноваты =).
кстати интересно на какую архитектуру и какое железо они воткнули солярку для сравнения...
Да, безусловно, бывает и так. Но в данном случае - "не верю (c)". DNS-сервер это достаточно тривиальная программа, немножко работы с файлами, куча работы с сокетами, довольно простой бинарный протокол, кеширование... и всё. Разница в производительности в 2 раза (!) между Linux и BSD, и почти в 5 раз (!!!) между Linux и Win - это бред! Если бы проблема была бы в каких то глобальных нерешаемых засадах, то на другом аналогичном софте (напр. веб-сервере Apache и других сетевых сервисах) мы бы наблюдали аналогичную разницу в производительности... но это не так. Как правило производительность таких сервисов на разных ОС сравнима, разница не превышает 10-20%, да и то это зачастую связано с кривизной рук админа.
да, но разница между FreeBSD 7 и федорой практически отсутсвует. Кстати в том же apache разница между bsd, линухом и виндовсом тоже существенна. В основном война идёт между kqueue и epoll.. Учитывая что сборки для bsd 6.2 и 7 - одинаковые и имеется разница в 40% - возможно тут и имеет место быть неоптимизированность, но скорее всего "отсутсвие хаков для уксорения на прошлых дистрибутивах" +)
Sign up to leave a comment.
Тест производительности BIND на разных OS