Comments 57
Пишите еще. Интересно. С этой загрузкой как я понимаю нужно под каждый домен делать 128 очередей и загружать уже там паралельно.
когда я так делал умирали некоторые сайты. среднее время сейчас на 1 страницу — меньше 2 секунд, прикиньте как умрет хостинг если за секунду просить по 100 страниц? Реальный пример — форум суммарно на 5000 сообщений умирал при 5 запросах в секунду
Когда-то делал RSS аггрегатор и знаю как это происходит :-) Так и не добрался до en.wikipedia.org/wiki/Robots_exclusion_standard robots.txt. А в режиме тестирования\разработки умерали конечно и сайты и провайдер. Задержка обязательна.
Гм. Поисковик ведь индексирует не один сайт. Что мешает запрашивать хоть 100 страниц в секунду, но со 100 разных сайтов? Или даже лучше с разных IP адресов/сетей, чтобы ненароком не положить один сервер держащий большое количество сайтов.
На практике целей на индексацию на много порядков больше, поэтому интенсивность обращения к каждой из них значительно ниже.
На практике целей на индексацию на много порядков больше, поэтому интенсивность обращения к каждой из них значительно ниже.
Sitemap примерно у сколько процентов сайтов есть?
Как часть Вы проводите повторную загрузку страницы для проверки актуальности информации? Или это не требуется для Ваших задач?
Откуда берёте список ресурсов для парсинга?
Происходит ли повторная проверка страницы спустя какое-то время, если в ответ приходит ответ сервера 5xx?
Откуда берёте список ресурсов для парсинга?
Происходит ли повторная проверка страницы спустя какое-то время, если в ответ приходит ответ сервера 5xx?
Общая очередь с приоритетами. Сейчас приоритет на индексацию никогда не индексированных сайтов — 9 к 1. Это все гибко меняется — сами понимаете какие то сайты типа новостных надо раз в сутки индексить, а какие-то раз в год. В очереди (это единственное что я храню в MySQL) можно проставлять приоритеты, и потом обычная взвешенная выборка
Список ресурсов — проходя по странице все ссылки на другие сайты попадают в 2 очереди — на индексацию и на обновление PR
Ошибка при загрузке понижает рейтинг сайта. 10 ошибок в разное время и ни одной рабочей страницы — и он будет браться из очереди очень редко, считай никогда
Список ресурсов — проходя по странице все ссылки на другие сайты попадают в 2 очереди — на индексацию и на обновление PR
Ошибка при загрузке понижает рейтинг сайта. 10 ошибок в разное время и ни одной рабочей страницы — и он будет браться из очереди очень редко, считай никогда
А как на счет днса от гугла 8.8.8.8?
По какой формуле рассчитываете PR? И есть ли аналог ТИЦ?
Не понял ключевой момент: откуда изначально имена сайтов берутся?
первый сайт — любой, например rambler.ru
дальше получаем контент — берем все ссылки. все ссылки на другие сайты с текущего попадают в общую очередь — только их главные страницы, все страницы с текущего сайта — в текущую очередь в пределах лимита.
Дорабатывая текущий сайт (лимит или кончились страницы) — берем из общей очереди новый сайт
дальше получаем контент — берем все ссылки. все ссылки на другие сайты с текущего попадают в общую очередь — только их главные страницы, все страницы с текущего сайта — в текущую очередь в пределах лимита.
Дорабатывая текущий сайт (лимит или кончились страницы) — берем из общей очереди новый сайт
UFO just landed and posted this here
UFO just landed and posted this here
про это и есть данный пост.
LWP и остальные готовые средства делают 1 запрос к ДНС на каждый запрос. Кеша там нет. В моем случае я сначала написал кеш, поработал с ним, потом понял что проще поднять локальный bind чем самому грамотно организовывать всю работу, тестировать ее.
Иметь сильно больше 100 потоков смысла нет — скорости обработки не хватит, надо же это все куда-то складывать.
Сам робот — многопотоковый, сокеты низкого уровня, асинхронные, довольно забавно собираются ответы серверов в целую страницу — но собственно все по спецификации TCP/IP ничего нового
LWP и остальные готовые средства делают 1 запрос к ДНС на каждый запрос. Кеша там нет. В моем случае я сначала написал кеш, поработал с ним, потом понял что проще поднять локальный bind чем самому грамотно организовывать всю работу, тестировать ее.
Иметь сильно больше 100 потоков смысла нет — скорости обработки не хватит, надо же это все куда-то складывать.
Сам робот — многопотоковый, сокеты низкого уровня, асинхронные, довольно забавно собираются ответы серверов в целую страницу — но собственно все по спецификации TCP/IP ничего нового
UFO just landed and posted this here
честных 20 на один порт
больше я не смог заюзать — есть машины и 100 и 1000, все равно не успеваю отрабатывать
больше я не смог заюзать — есть машины и 100 и 1000, все равно не успеваю отрабатывать
Во что упираетесь?
Сложно сказать — все вместе
Надо собрать хотя бы 1000 страниц, это 10-100 мб, распарсить-сохранить, ссылки в очередь добавить
Возможно нужен просто пустой сервак для чистоты эксперимента, возможно винч не успевает. Если иметь сильно больше сайтов в параллель растет загрузка по отработке очереди
Основная то работа по сохранению, а не по загрузке
Надо собрать хотя бы 1000 страниц, это 10-100 мб, распарсить-сохранить, ссылки в очередь добавить
Возможно нужен просто пустой сервак для чистоты эксперимента, возможно винч не успевает. Если иметь сильно больше сайтов в параллель растет загрузка по отработке очереди
Основная то работа по сохранению, а не по загрузке
Интересная тематика :)
На чем написали crawler?
Какой функционал реализовали в нем? Как?
Как поступаете с сайтами, где внутренние ссылки сгенерированы (например, содержат какой-нибудь постоянно меняющийся id)? А если еще и часть каждой выдачи страницы будет уникальной (например, серверное дата/время)
На чем написали crawler?
Какой функционал реализовали в нем? Как?
Как поступаете с сайтами, где внутренние ссылки сгенерированы (например, содержат какой-нибудь постоянно меняющийся id)? А если еще и часть каждой выдачи страницы будет уникальной (например, серверное дата/время)
я храню очередь только главных страниц. Все проиндексированные в другой базе — уже собственно поисковика, там полные url.
Соответственно фазы сбора url и их индексации во времени близко стоят, друг за другом, — много ссылок не меняется.
Есть варианты робота на Perl, C++. В основном юзаю C++ — меньше грузит сервер, как понятно
Все неуникальное отрезается — чуть дальше опишу, в этом и есть весь функционал —
запрос — сбор ответа/выделение ссылок на другие страницы — сохранение — анализ всего сайта — отрезание одинакового — сохранение — сортировка очереди
Серверное время останется, ничего не сделать — но таких сайтов единицы.
Товарищи, поймите, там годы работы и экспериментов — я не могу написать сразу все, у меня рук не хватит
Соответственно фазы сбора url и их индексации во времени близко стоят, друг за другом, — много ссылок не меняется.
Есть варианты робота на Perl, C++. В основном юзаю C++ — меньше грузит сервер, как понятно
Все неуникальное отрезается — чуть дальше опишу, в этом и есть весь функционал —
запрос — сбор ответа/выделение ссылок на другие страницы — сохранение — анализ всего сайта — отрезание одинакового — сохранение — сортировка очереди
Серверное время останется, ничего не сделать — но таких сайтов единицы.
Товарищи, поймите, там годы работы и экспериментов — я не могу написать сразу все, у меня рук не хватит
Хмм… а почему не использовать модули, которые уже есть?
Другой вопрос — как фильтруете календари — от них можно получить 100500 ссылок и больше.
Другой вопрос — как фильтруете календари — от них можно получить 100500 ссылок и больше.
Все описано — асинхронная многопотоковость на уровне 100 запросов в секунду, обработка, сохранение. Лишние запросы к ДНС, большая загрузка
Универсальность всегда неэффективна по сравнению с заточенным под задачу решением, особенно если ее собирать из кусков. Crawler на Perl есть — там как раз модульное, раз в 10 медленнее чем C++ и сокеты низкого уровня.
Календари? Никак. Я беспристрастен — если автор считает что главное что есть на его сайте это ссылки на числа календаря то его право. В топ он может по запросу — конкретной дате — и выйдет, а дальше сам виноват. Поверьте у большинства поисковиков такая же позиция
Универсальность всегда неэффективна по сравнению с заточенным под задачу решением, особенно если ее собирать из кусков. Crawler на Perl есть — там как раз модульное, раз в 10 медленнее чем C++ и сокеты низкого уровня.
Календари? Никак. Я беспристрастен — если автор считает что главное что есть на его сайте это ссылки на числа календаря то его право. В топ он может по запросу — конкретной дате — и выйдет, а дальше сам виноват. Поверьте у большинства поисковиков такая же позиция
Таки вопрос был почему скажем не взять heritrix, допилить под себя и запустить?
С календарями проблема не в том, что считает автор, а в том, как от отфильтровать 100500 страниц календарей от реального контента. Это задача уже автора поисковика.
С календарями проблема не в том, что считает автор, а в том, как от отфильтровать 100500 страниц календарей от реального контента. Это задача уже автора поисковика.
Очень просто — Вы забываете что все равно хранить придется, их не выкинуть. Какой-нить одаренный все равно вынесет вам мозг по поводу того что страниц его сайта нет в выдаче, а другой будет икать если по запросу 25.02.2002 ничего не найдется — так что индексим и складываем подальше. Слова-цифры мало котируются в индексе и запросе, к ним будет доступ только если напрямую введут запрос и особенно они не мешают работе
По поводу того что забьется очередь на индексацию — да, конкретно с этим сайтов забьется. Возможно вы правы что можно по url + немного анализа контента выделить еще и значимые страницы, но эта идея будет в списке доделок не первой )
По поводу того что забьется очередь на индексацию — да, конкретно с этим сайтов забьется. Возможно вы правы что можно по url + немного анализа контента выделить еще и значимые страницы, но эта идея будет в списке доделок не первой )
Недавно читал об архитектуре поисковой системы Turtle в тексте достаточно подробно рассмотрен процесс создания поисковой системы, однако сам сайт достаточно старый (2003-2007 год, судя по подписи внизу страницы). Сам поисковик к сожалению не работает.
Получилось что-то около 20-30 тысяч страниц в час,
Смеетесь? хм. это разве что с одного сайта и то скорее в целях щадящего режима к конкретному сайту). Если использовать параллельную загрузку с разных сайтов цифры совсем другие.
С простого сервера на firstvds.ru — 300Mhz, 256RAM — я сохранял в среднем по 10-16тысяч страниц в минуту.
Индексные страницы рунета собирались у меня где-то за 3.0 — 4.5 часа. На тот момент в зоне ru было около 1.2млн зарегистрированных имен.
Чуть не забыл — тогда это был обычный php + multicurl )
ну вас можно только поздравить вы получили бы сейчас скорость минимум 1гб в минуту, или 133 mbit/s полезной инфы, учитывая что не более 40%-60% канала реально можно занять полезной инфой, и даже не учитывая время на запросы ДНС, поскольку объем одной страницы сейчас в среднем около 100кб до отрезания всего.
Да, и я хорошо представляю себе счет за перерасход траффика за несоблюдение соглашения по соотношению 1:3 минимум…
Мой потолок — 200 тысяч страниц в час без проверки контента
Да, и я хорошо представляю себе счет за перерасход траффика за несоблюдение соглашения по соотношению 1:3 минимум…
Мой потолок — 200 тысяч страниц в час без проверки контента
Заапросов к ДНС — всего-то по количеству опрашиваемых доменов. Блок кеширующий записи днс для домена можно сделать на коленке за полчасика. В конфиг вынести время жизни записи и можно дальше не обращать внимания на днс до поры до времени.
Уже года 3-4 точно можно с легкостью найти сервер без подобных ограничений за обычную плату.
Другой вопрос, если скорость непосредственной обработки информации относительно невелика, а зачастую так и будет, если это эксперименты (там ведь не до оптимизаций) — то возможно Вам и нет смысла ускорять crawler. Просто хотел указать, что приведенные цифры для crawler'а — это не ограничение, а просто цифры которые получились у вас и при случае их с легкостью можно увеличить.
Уже года 3-4 точно можно с легкостью найти сервер без подобных ограничений за обычную плату.
Другой вопрос, если скорость непосредственной обработки информации относительно невелика, а зачастую так и будет, если это эксперименты (там ведь не до оптимизаций) — то возможно Вам и нет смысла ускорять crawler. Просто хотел указать, что приведенные цифры для crawler'а — это не ограничение, а просто цифры которые получились у вас и при случае их с легкостью можно увеличить.
А вы посылаете Accept-Encoding => gzip,deflate?
Это может примерно в 10 раз снизить трафик.
Это может примерно в 10 раз снизить трафик.
хорошая идея, но и повысить загрузку сервера, кроме того по умолчанию, насколько я знаю, в апаче опция отключена.
проверю вечерком работает ли, с другой стороны это повысит загрузку моего сервера — а он не резиновый, и так под завязку
проверю вечерком работает ли, с другой стороны это повысит загрузку моего сервера — а он не резиновый, и так под завязку
Я имеюьввиду один модуль, например downloader ( или что у вас там). За одно рассказали бы нам как их связываете чтобы они одно и тоже не делали
Грубо говоря выход Crawler-а это файл для каждого сайта для последующей индексации. По мере их появления (10 роботов могут класть удаленно файлы в каталог для индексации) их берет индексатор и уже делает кусочек индекса — который потом добавляется к основному. Про индексатор и методику инкрементального построения индекса тоже напишу подробно
Вероятность что 10 crawler'ов будут индексить один сайт весьма мала — сайты выбираются из очереди исходя из даты начала индексации (чем больше прошло тем лучше), весов, кол-ва страниц и тд. Т.е. начиная очередной сайт crawler просто проставляет текущую дату и следующий робот уже этот сайт не возьмет.
Это в двух словах
Вероятность что 10 crawler'ов будут индексить один сайт весьма мала — сайты выбираются из очереди исходя из даты начала индексации (чем больше прошло тем лучше), весов, кол-ва страниц и тд. Т.е. начиная очередной сайт crawler просто проставляет текущую дату и следующий робот уже этот сайт не возьмет.
Это в двух словах
Было бы очень интересно услышать про используемый Вами алгоритм ранжирования. Это стандартная Okapi BM 25 или еще какие-то собственные модели?
А куда вы записываете загруженные страницы? Я когда писал краулер столкнулся с проблемой со скоростью записи в базу (писал в postgresql пачку страниц длинным инсертом).
Почему-то всегда думал что днс кэшируется на уровне ОС, а оказывается вот оно как…
Почему-то всегда думал что днс кэшируется на уровне ОС, а оказывается вот оно как…
Собственная БД. Вернее одна из собственных — в одной индекс, в другой инфа по страницами и словам разнообразная, в третьей PR, в четвертой тексты. Но для упрощения можно считать что просто пишу на диск в хитрую структуру каталогов и файлов с быстрым последовательным доступом. Тоже расскажу, я реально просто не могу все описать за 1 день :)
Имхо, не очень этично столь интенсивно опрашивать сайты. Может быть кто-то хостится в облаке и ему приходится переплачивать за эту бесполезную нагрузку, у кого-то может быть из-за перегрузки реальные клиенты не могут сделать заказ и тд.
Может быть стоит сделать простенький адаптивный алгоритм? Например, если время между ответами с одного сервера возрастает, то нужно увеличивать паузу между следующими запросами.
Может быть стоит сделать простенький адаптивный алгоритм? Например, если время между ответами с одного сервера возрастает, то нужно увеличивать паузу между следующими запросами.
Делайте, плз, ссылки на прошлые статьи цикла в новой — чтобы не пропустить какую, + чтобы, если захочется вспомнить «что было в прошлой серии», не приходилось искать.
При решении подобной задачи я открывал до 100 потоков на 100 разных сайтов (пробовал и 200, но скорость это уже практически не влияло). Грузил за раз не более одной страницы с сайта. Ответы днс кэшировал внутри программы и хранил, пока сайт в работе. Плюс проверял еще одну фишку — при получении данных днс для нового сайта проверял, если аналогичный IP уже есть в кэше, новый сайт ставился в очередь ожидания, а в обработку поступал следующий из очереди. Т.е. старался придерживаться не только правила «один поток на сайт», но и «один поток на сервер». Для нескольких виртуальных серверов на одной машинке это не пройдет, но тут уже наука бессильна. По крайней мере мне решение такого вопроса не известно.
Sign up to leave a comment.
С чего начинается поисковик, или несколько мыслей про crawler