Проверить NS через DNS - 100к доменов за 1 минуту - это много или мало?

[BAZAg]

Была когда-то тема, еще до времен AI.
Там я рассказывал о проверке доменов на наличие NS записей.

И вот спустя много лет у меня появился вопрос - сколько максимально доменов можно проверить за 1 минуту на одном пк/сервере?
Кто-то вообще задавался таким вопросом?
Каких результатов получилось достичь и каким способом?

В данный момент мне получается проверять примерно 100к/минуту.
Но... Что-то мне подсказывает что можно ещё ускориться (процессор 10-15%, интернета также хватает).

 

[BAZAg]

Да, все же получилось удвоить скорость в 2 раза - тоесть вижу реально можно делать 200к проверок DNS в минуту.

На данном скриншоте результат получен на 256 потоках.
Ожидание ответа DNS не больше 2 секунд.

На 512 потоках и ожиданием 1 секунда - результат хуже (много потоков не дождались ответа).


Интересное то, что при 1024 потоках процессор уходит в 100% на какое-то время но вроде работает.
Интернет кушает около 10 Мбит/с.
При 256, 512 - держится на 10-20%, интернет чуть меньше (6-7Мбит/с).

Ниже 1024 потоков:


Собственно, выводы из всего этого - на моем процессоре, и моей сетевой карте - 200к проверок в минуту.
Оптимальный вариант крутиться в пределах 192-256 потоков.

Ниже 192 потока:


Если брать во внимание, что всех доменов в мире около 350 млн, тогда, полная проверка всех доменов, чтобы держать их в актуальном состоянии может занимать около 30 часов. Или, нужно держать 2 сервера которые будут заниматься этой работой в бесперерывном потоке.

Во всем что я здесь описал не учитывается то, что данные нужно откуда-то брать, куда-то сохранять результат, что также может повлечь за собой дополнительные временные издержки.

Хотя, опыт получился интересный.

 

[deukech]

ну брать это одно - если имеется ввиду пополнение списка доменов то бд, а вот если чтение/запись, то почему бы не работать с бд в памяти и асинхронными снапшотами на диск..по сути все будет очень быстро крутиться в оперативе. вопрос уже архитектурный)

куда-то сохранять результат, что также может повлечь за собой дополнительные временные издержки.

 

[borroza]

ну брать это одно - если имеется ввиду пополнение списка доменов то бд, а вот если чтение/запись, то почему бы не работать с бд в памяти и асинхронными снапшотами на диск..по сути все будет очень быстро крутиться в оперативе. вопрос уже архитектурный)

Интересно, а как вы собираетесь 350 млн строк с данными доменов, ns серверов, ip адресов держать в ОЗУ?

 

[deukech]

Интересно, а как вы собираетесь 350 млн строк с данными доменов, ns серверов, ip адресов держать в ОЗУ?

Ну вот зачем это все? ну вот если соберусь, то подумаю на какие чанки бить, сколько держать в памяти а сколько дампить на диск,как часто, как лучше, даже,уверен, что сделаю несколько гипотез и тестов. Если рассматривать требование как "приортитет скорости", то остальное будет "жертвой" и не регламентируется, значит строим архитектуру исходя из здравого смысла и ресурсов.
и зачем держать " с данными доменов, ns серверов, ip адресов держать в ОЗУ?" тоже хз) их надо собирать и обновлять циклически.
Да и на хорошем серваке это по грубым прикидкам 128Гб несжатых данных

 

[BAZAg]

ну брать это одно - если имеется ввиду пополнение списка доменов то бд, а вот если чтение/запись, то почему бы не работать с бд в памяти и асинхронными снапшотами на диск..по сути все будет очень быстро крутиться в оперативе. вопрос уже архитектурный)

Спасибо! В реальности я очень далек от "работать с базой в памяти" и от "асинхронных снапшотов".
Хотя, возможно это просто какие-то определенные настройки самой базы.

Интересно, а как вы собираетесь 350 млн строк с данными доменов, ns серверов, ip адресов держать в ОЗУ?

Вы правы! Весь объем данных совершенно нет необходимости держать в оперативной памяти.
В моем случае скорость обработки около 1 000 000 каждых 5 минут.
Примерно на этой скорости есть смысл обеспечить подачу данных на обработку.
Это примерно 20мб данных в виде доменов (или 80мб если домен+нс1+нс2+IP) - что полностью приемлимо.

Ну вот зачем это все? ну вот если соберусь, то подумаю на какие чанки бить, сколько держать в памяти а сколько дампить на диск,как часто, как лучше, даже,уверен, что сделаю несколько гипотез и тестов. Если рассматривать требование как "приортитет скорости", то остальное будет "жертвой" и не регламентируется, значит строим архитектуру исходя из здравого смысла и ресурсов.
и зачем держать " с данными доменов, ns серверов, ip адресов держать в ОЗУ?" тоже хз) их надо собирать и обновлять циклически.
Да и на хорошем серваке это по грубым прикидкам 128Гб несжатых данных

Как я выше написал - работать я собрался порциями по 1млн (20мб) сырых доменов.
Уже исходя из этого брать сервера на 128гб или строить решение которое будет использовать столько памяти мне выглядит избыточным. Хотя, возможно я ещё чего-то не вижу (что также не исключаю).

В реальности на текущий момент я все ещё не определился с тем, что мне делать с информацией, которая была получена.
Хотя примерный план решения вижу примерно таким (речь уже о возможности держать актуальную информацию о всех доменах интернета):

Так как привык работать с MySQL, значит для хранения данных её и буду использовать.
Чтобы не обращаться к ней напрямую - напишу что-то вроде API на PHP+Swagger.
Возможно где-то в конфигах нужно будет подправить время до разрыва соединения, чтобы когда буду отправлять пачки по 10к доменов соединение не разрывалось преждевременно (с ходу помню, что была какая-то у меня проблема что больше 1000 записей не удавалось добавлять, не хватало времени).

А дальше просто напишу шаблон Зенно
Он будет спрашивать базу зону, которая протухла.
Если такая есть - будет скачивать её.
А дальше пачками по этих 10к обычными запросами к API будет добавлять в базу (или обновлять время).
После чего - удалять все домены этой зоны, у которых протухло время.
Это и даст мне постоянные актуальные домены в базе.
Здесь фактически потребления памяти и процессора быть не должно, важно наверно чтобы оно успевало выкачивать новые данные каждых 30 часов (скорость проверки всех).

Второй шаг в этой истории - это как-то обеспечить возможность обработки на нескольких серверах.
Проблема, которая сразу всплывет - это получение этого 1млн доменов, так как их нужно как-то получить, и потом как-то после обработки вернуть обратно уже с новыми данными.
Чтобы обойти это место, наверно будет сделан шаблон, который будет брать например этих 10к записей определенной зоны и отправлять их в Rabbit. Тоесть, будет обеспечено например хранение 1-5 млн записей в очереди.

Шаг третий - это то решение, о котором эта тема - шаблон который будет брать с очереди 1 млн, производить проверку, возвращать данные обратно в Rabbit, в другую очередь. Здесь идея в том, что таких обработчиков может быть несколько независимых на разных серверах, которые не будут создавать какой-то дискомфорт для базы.

И последний - это уже разбор очереди успехов и не успехов и обновление нужных данных в базе.

Это по идее должно позволить зациклить весь процесс - первый берет время от времени зоны и обновляет их.
Второй видит какие домены стоит отправить на проверку - занимается их отправкой на обработку.
Обработчики производят обогащение данных и возвращают результат не зависимо от базы или ожидают пока в очереди появлятся данные.
И последний просто ожидает данные в очереди и разгребает их с удобной для себя скоростью.

Как-то так я вижу дальнейшее развитие этой истории.
Если у кого-то есть какие-то советы или критика по поводу что я где-то ошибаюсь - пишите!

 

[deukech]

Спасибо! В реальности я очень далек от "работать с базой в памяти" и от "асинхронных снапшотов".
Хотя, возможно это просто какие-то определенные настройки самой базы.


Вы правы! Весь объем данных совершенно нет необходимости держать в оперативной памяти.
В моем случае скорость обработки около 1 000 000 каждых 5 минут.
Примерно на этой скорости есть смысл обеспечить подачу данных на обработку.
Это примерно 20мб данных в виде доменов (или 80мб если домен+нс1+нс2+IP) - что полностью приемлимо.


Как я выше написал - работать я собрался порциями по 1млн (20мб) сырых доменов.
Уже исходя из этого брать сервера на 128гб или строить решение которое будет использовать столько памяти мне выглядит избыточным. Хотя, возможно я ещё чего-то не вижу (что также не исключаю).

В реальности на текущий момент я все ещё не определился с тем, что мне делать с информацией, которая была получена.
Хотя примерный план решения вижу примерно таким (речь уже о возможности держать актуальную информацию о всех доменах интернета):

Так как привык работать с MySQL, значит для хранения данных её и буду использовать.
Чтобы не обращаться к ней напрямую - напишу что-то вроде API на PHP+Swagger.
Возможно где-то в конфигах нужно будет подправить время до разрыва соединения, чтобы когда буду отправлять пачки по 10к доменов соединение не разрывалось преждевременно (с ходу помню, что была какая-то у меня проблема что больше 1000 записей не удавалось добавлять, не хватало времени).

А дальше просто напишу шаблон Зенно
Он будет спрашивать базу зону, которая протухла.
Если такая есть - будет скачивать её.
А дальше пачками по этих 10к обычными запросами к API будет добавлять в базу (или обновлять время).
После чего - удалять все домены этой зоны, у которых протухло время.
Это и даст мне постоянные актуальные домены в базе.
Здесь фактически потребления памяти и процессора быть не должно, важно наверно чтобы оно успевало выкачивать новые данные каждых 30 часов (скорость проверки всех).

Второй шаг в этой истории - это как-то обеспечить возможность обработки на нескольких серверах.
Проблема, которая сразу всплывет - это получение этого 1млн доменов, так как их нужно как-то получить, и потом как-то после обработки вернуть обратно уже с новыми данными.
Чтобы обойти это место, наверно будет сделан шаблон, который будет брать например этих 10к записей определенной зоны и отправлять их в Rabbit. Тоесть, будет обеспечено например хранение 1-5 млн записей в очереди.

Шаг третий - это то решение, о котором эта тема - шаблон который будет брать с очереди 1 млн, производить проверку, возвращать данные обратно в Rabbit, в другую очередь. Здесь идея в том, что таких обработчиков может быть несколько независимых на разных серверах, которые не будут создавать какой-то дискомфорт для базы.

И последний - это уже разбор очереди успехов и не успехов и обновление нужных данных в базе.

Это по идее должно позволить зациклить весь процесс - первый берет время от времени зоны и обновляет их.
Второй видит какие домены стоит отправить на проверку - занимается их отправкой на обработку.
Обработчики производят обогащение данных и возвращают результат не зависимо от базы или ожидают пока в очереди появлятся данные.
И последний просто ожидает данные в очереди и разгребает их с удобной для себя скоростью.

Как-то так я вижу дальнейшее развитие этой истории.
Если у кого-то есть какие-то советы или критика по поводу что я где-то ошибаюсь - пишите!

я много писать не очень мастер и ленивец, но вот выкладка по моим мыслям

Спойлер: redis

Как работает сохранение на диск (Персистентность)​

Чтобы гарантировать сохранность данных, in-memory базы используют два основных подхода, которые часто применяются вместе:

1. Снимки (RDB — Redis Database): Это то, что вы и описали. База данных создает "моментальный снимок" (snapshot) всех данных в определенный момент и записывает его на диск в виде компактного бинарного файла.
   
   • Плюсы: Создание снимка происходит очень быстро (часто с помощью механизма fork, который создает дочерний процесс, не прерывая работу основного), файл получается компактным, и восстановление из него при запуске происходит быстрее, чем из журнала изменений.
   • Минусы: Это "точечное" сохранение. Если сервер упадет между двумя снимками, все изменения, сделанные после последнего снимка, будут потеряны.
2. Журнал изменений (AOF — Append Only File): В этом режиме база данных записывает в специальный лог-файл каждую команду, которая изменяет данные (например, SET, DEL). При перезапуске сервер просто проигрывает этот лог заново, чтобы восстановить состояние базы.
   
   • Плюсы: Гораздо более высокая надежность. Можно настроить частоту записи на диск (например, раз в секунду), что сводит потенциальную потерю данных к минимуму.
   • Минусы: Файл AOF может вырасти до огромных размеров и медленнее восстанавливаться по сравнению со снимком RDB.

Стратегии для ваших DNS-данных​

Для вашего случая с DNS-данными есть несколько проверенных вариантов:

• Redis с RDB: Отличный выбор, если вы можете позволить себе потерять несколько минут данных в случае аварии, но вам нужна максимальная производительность и быстрая перезагрузка сервера.
• Redis с AOF + RDB: Это "золотой стандарт" надежности. Вы получаете и быстрые снимки для перезагрузки, и детальный журнал изменений для минимальной потери данных. Настройка позволяет найти баланс между производительностью и надежностью.
• Специализированные DNS-решения: Существуют проекты, изначально разработанные для высокоскоростного кэширования DNS. Например, GRDNS — это DNS-сервер, написанный на Go, который использует Redis в качестве основного хранилища для максимальной скорости. Или BIND SDB, который может хранить зоны не в оперативной памяти, а в базах данных, таких как PostgreSQL, но с возможностью работы в памяти.

Практический пример​

Вы можете настроить Redis так, чтобы он создавал снимок RDB каждые 5 минут, если в базе произошло хотя бы 100 изменений. Это дает отличный баланс: производительность на максимуме, а риски потери данных сведены к минимуму.

Если вы присматриваетесь к инфраструктуре для работы с такими объемами, стоит обратить внимание на управляемые облачные решения (например, от Azure, IONOS), которые предлагают готовые кластеры Redis с уже настроенной политикой сохранения данных (персистентности).

 

[borroza]

я много писать не очень мастер и ленивец, но вот выкладка по моим мыслям

Спойлер: redis

Как работает сохранение на диск (Персистентность)​

Чтобы гарантировать сохранность данных, in-memory базы используют два основных подхода, которые часто применяются вместе:

1. Снимки (RDB — Redis Database): Это то, что вы и описали. База данных создает "моментальный снимок" (snapshot) всех данных в определенный момент и записывает его на диск в виде компактного бинарного файла.
   • Плюсы: Создание снимка происходит очень быстро (часто с помощью механизма fork, который создает дочерний процесс, не прерывая работу основного), файл получается компактным, и восстановление из него при запуске происходит быстрее, чем из журнала изменений.
   • Минусы: Это "точечное" сохранение. Если сервер упадет между двумя снимками, все изменения, сделанные после последнего снимка, будут потеряны.
2. Журнал изменений (AOF — Append Only File): В этом режиме база данных записывает в специальный лог-файл каждую команду, которая изменяет данные (например, SET, DEL). При перезапуске сервер просто проигрывает этот лог заново, чтобы восстановить состояние базы.
   • Плюсы: Гораздо более высокая надежность. Можно настроить частоту записи на диск (например, раз в секунду), что сводит потенциальную потерю данных к минимуму.
   • Минусы: Файл AOF может вырасти до огромных размеров и медленнее восстанавливаться по сравнению со снимком RDB.

Стратегии для ваших DNS-данных​

Для вашего случая с DNS-данными есть несколько проверенных вариантов:

• Redis с RDB: Отличный выбор, если вы можете позволить себе потерять несколько минут данных в случае аварии, но вам нужна максимальная производительность и быстрая перезагрузка сервера.
• Redis с AOF + RDB: Это "золотой стандарт" надежности. Вы получаете и быстрые снимки для перезагрузки, и детальный журнал изменений для минимальной потери данных. Настройка позволяет найти баланс между производительностью и надежностью.
• Специализированные DNS-решения: Существуют проекты, изначально разработанные для высокоскоростного кэширования DNS. Например, GRDNS — это DNS-сервер, написанный на Go, который использует Redis в качестве основного хранилища для максимальной скорости. Или BIND SDB, который может хранить зоны не в оперативной памяти, а в базах данных, таких как PostgreSQL, но с возможностью работы в памяти.

Практический пример​

Вы можете настроить Redis так, чтобы он создавал снимок RDB каждые 5 минут, если в базе произошло хотя бы 100 изменений. Это дает отличный баланс: производительность на максимуме, а риски потери данных сведены к минимуму.

Если вы присматриваетесь к инфраструктуре для работы с такими объемами, стоит обратить внимание на управляемые облачные решения (например, от Azure, IONOS), которые предлагают готовые кластеры Redis с уже настроенной политикой сохранения данных (персистентности).

ну мне бы как то стыдно было.... человек мысли от себя излагает - а вы в ии скормили и ответ кинули - это на уровне - пошел нахер и абсолютное не уважение.......

 

[BAZAg]

я много писать не очень мастер и ленивец, но вот выкладка по моим мыслям

Кэширующие DNS решения - чуток не туда (суть в актуальности данных по сравнению с готовыми базами - иначе брал бы готовые базы ICANN) и не думал о том, как бы вытаскивать нужные данные с первоисточников.

К Redis я пока "не дорос" - фактически это и собрался обеспечить в ОЗУ используя пачки по 1млн строчек (тоесть то, что будет выполняться на уровне одного потока Зеннопостера будет находиться в ОЗУ, что и должно давать необходимую производительность).

Проблемные места - это фактически заливка данных в базу, получение данных с базы, обновления данных в базе - ведь когда речь идет о миллионах строчек - то здесь уже нужно будет на практике смотреть, пока не столкнулся лбом - сложно что-то предполагать. По 10к думаю без проблема должно залетать, а вот пачками побольше - не уверен.

Пока что я с такими большими объемами данных не работал (точнее работал, но тогда времени было достаточно, пачками по 1к приходилось заливать данные) - и может оказаться что мой подход с PHP будет отрабатывать слишком долго, из-за чего придется работать с базой напрямую (чего я собственно и стараюсь избежать).

ну мне бы как то стыдно было.... человек мысли от себя излагает - а вы в ии скормили и ответ кинули - это на уровне - пошел нахер и абсолютное не уважение.......

Это не страшно. Мне важно сейчас получить взгляд со стороны - чем больше людей приняло бы участие - тем лучше.
У каждого ведь свой опыт, свои мысли, свои подходы к решению подобных задач.
AI часто помогает структурировать материал.
Но, чтобы что-то структурировать - нужно иметь исходный материал для анализа.
Любые идеи приветствуются!

 

[deukech]

ну мне бы как то стыдно было.... человек мысли от себя излагает - а вы в ии скормили и ответ кинули - это на уровне - пошел нахер и абсолютное не уважение.......

мне давно ни за что не стыдно, а чужие проекции как-то мало интересуют. мало ли кому чего там кажется.
по сути я наилучшим образом сформулировал мысль при помощи инструмента.. я же напрягся - "скормил" свои корявенькие мысли и получил уже оформленное.
тем более,я в личке обещал что может чего нарою/вспомню по теме)

впрочем, вам то чего быть недовольным?

 

[deukech]

но тогда времени было достаточно,

а стоит ли торопиться? если я правильно услышал, то по сути всех устраивает текущее положение вещей и вся задача строится только на вашем исследовательском интересе, а не на необходимости.

 

[borroza]

мне давно ни за что не стыдно, а чужие проекции как-то мало интересуют. мало ли кому чего там кажется.
по сути я наилучшим образом сформулировал мысль при помощи инструмента.. я же напрягся - "скормил" свои корявенькие мысли и получил уже оформленное.
тем более,я в личке обещал что может чего нарою/вспомню по теме)

впрочем, вам то чего быть недовольным?

ну потом и вытекают такие исполнители как вы - абы деньги и побольше с клиента и нафиг что он там вякает - на отьебись все - умными фразами от ИИ. удачи маэстро))

 

[BAZAg]

мне давно ни за что не стыдно, а чужие проекции как-то мало интересуют. мало ли кому чего там кажется.
по сути я наилучшим образом сформулировал мысль при помощи инструмента.. я же напрягся - "скормил" свои корявенькие мысли и получил уже оформленное.
тем более,я в личке обещал что может чего нарою/вспомню по теме)

впрочем, вам то чего быть недовольным?

Не стоит переживать.
Нашли время вникнуть в вопрос и ответить - это уже хорошо.
Неделю ведь тема висит - видно же что люди заходят, читают, но ответить в теме стесняются.
Тема то специфическая...

а стоит ли торопиться? если я правильно услышал, то по сути всех устраивает текущее положение вещей и вся задача строится только на вашем исследовательском интересе, а не на необходимости.

Как-то так повелось, что я решаю в основном те задачи, которые мне самому лично чем-то интересны.
Тоесть, если меня сейчас интересуют домены, почты, очереди - то по дороге я с удовольствием берусь за выполнение такой работы.
И наоборот - если меня не интересует работа в браузере или работа с социальными сетями, мобильными эмуляторами и тп - то соответственно от такой работы с сразу отказываюсь не вникая в подробности.
Так и в случае с проверкой доменов на записи через DNS - это ведь не только о том, как получить данные - этот вопрос куда шире - построение системы, которая может выдавать необходимый результат с приемлимой скоростью.
Если к примеру убрать проверку DNS, заменив это место например на парсинг данных - то фактически ничего не изменится - всю систему при желании можно адаптировать под новый тип задач.

А уже публичные разговоры на подобные темы на форуме - это ведь что-то вроде визитной карточки.
Кто-то будет искать решение подобной задачи - почитает тему, может быть обратится за помощью.
Личный же интерес - это плюс одна интересная задачка в копилку, которую смог решить.

ну потом и вытекают такие исполнители как вы - абы деньги и побольше с клиента и нафиг что он там вякает - на отьебись все - умными фразами от ИИ. удачи маэстро))

Чтобы AI смог помочь, нужно знать что у него спрашивать.
У каждого сейчас AI под рукой.
Неделю провисела тема мертвая, без обсуждений.
Никто особо не желает на форуме помогать бесплатно и публично (так как публично - сразу видно человек сам делал или AI).
Странно что вообще не появились персонажи, которые порекомендовали бы мне пойти к AI за помощью или в рекламный раздел и там найти исполнителя.

В не простое время живем...

 

[deukech]

ну потом и вытекают такие исполнители как вы - абы деньги и побольше с клиента и нафиг что он там вякает - на отьебись все - умными фразами от ИИ. удачи маэстро))

Вы о чем вообще?)
Я понимаю, что накипело где-то, но я то при чем?)
Колкости ваши в мой адрес не понятны. Совершенно незаслужено

умными фразами от ИИ

Воспримите то, что под спойлером было, как выкладку из справочника. из умного справочника, который смог структурировать кривую мысль в структуру по пунктам. Поверьте "само" оно так не умеет, его пнуть надо))
а все, что кроме - как мое личное, эксклюзивное, по мере сил и возможностей в рамках конкретного диалога и отрезка времени))