DomParser для парсинга сайтов- нагрузка в больших проектах

[jDony]

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

А что до объёмов... Раньше я сливал контакт с этим инструментом и когда скрипт тупо пошёл до 1 гигобайта памяти - переписал на регулярки и радовался. Сейчас не хочу менять инструмент если вдруг внезапно будет хтмп большой или ещё чтото.
По объёмам -хз, может 10 страниц в секунду. Ну и работа - час, два. Просто не хочется проектировать чтото с учётом багов. Есть вариант использовать примитивные домпарсеры на регулярках и strpos - но тогда сложные какие то вещи использовать нельзя.
Сейчас протестировал по моему всё серьёзные компоненты (не брал встроенный)- зенд, симфони и парней с хабра показали себя хорошо. Но тестил примитивно. В скором времени выложу нормальный отчёт со сравнением и бенчарк.

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

Используете ли вы на таких объемах подход с несколькими воркерами и централизированной очередью?
Т.е:
1 скрипт генерирует\парсит нужные урл и складывает их во внешнюю очередь (да тот же Redis или ironMQ)
2. сколько угодно воркеров которые забирают от туда данные и обрабатывают их.

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

 

[latteo]

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

Вроде есть еще отдельная функция для циклических ссылок - gc_collect_cycles - Для просмотра ссылки Войди или Зарегистрируйся

Команда над оптимизацией скорости работает (смотри атач), так что имеет смысл попробовать последние версии пыха - 5.5.* вдруг порадуют

 

[dwarf]

Используете ли вы на таких объемах подход с несколькими воркерами и централизированной очередью?

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

 

[асс]

А это все обрабатывается кроном?

Почему не использовать ограничение по выполнению скрипта?
Например
void set_time_limit ( int $seconds )

Задает время в секундах, в течение которого скрипт должен завершить работу. Если скрипт не успевает, вызывается фатальная ошибка. По умолчанию дается 30 секунд, либо время, записанное в настройке max_execution_time в php.ini (если такая настройка установлена).

Я при проверке парсером запускаю сркипт, через 2 минуты он умирает, а новый кроном вызывается повторно, и так бесконечно.

Или это не лучшее решение?

 

[latteo]

Я при проверке парсером запускаю сркипт, через 2 минуты он умирает, а новый кроном вызывается повторно, и так бесконечно.

2 минуты слишком мало за это время много памяти не утечёт слишком мало, а перезапуск скрипта - это дополнительная нагрузка на дисковую систему (читается кучка файлов) и замедление времени работы за счёт расхода времени процессора на первичную инициализацию и завершение. Я как-то доэкспериментировался с расширениями php до того, что у меня завершение работы скрипта типа <? echo 'hello'; ?> занимало 2-3 секунды + до 5 секунд на загрузку

Иногда парсеры пишутся так, что смерть во время работы может нарушить структуру БД и не всегда это от кривых рук...

 

[асс]

Иногда парсеры пишутся так, что смерть во время работы может нарушить структуру БД и не всегда это от кривых рук...

Согласен что база глюкнет и может выдать проблемы, но это редкие случаи, как мне кажется.
хотя отвалится может в любой момент.
Я парсеры использую простые, да и зависит от контента, если это новость то перед внесением вбазу делаю проверку на существование вбазе, и на объем контента, если контента мало или нет тогда делаю выход скрипта.

У меня новостник 6 лет работает, парсер не разу не подвел.

 

[Darkmind]

SimpleHTMLDOM страдает от утечек памяти при больших объёмах парсинга. С этим можно пытаться бороться принудительным destroy() для создаваемых объектов, но память всё равно течёт. Задачу по парсингу большого объёма данных (база адресов, несколько десятков тысяч страниц, несколько сотен тысяч записей в базу данных) решал на phpQuery. Не течёт, приемлемая скорость работы, привычные jQuery-like селекторы для парсинга страниц.

P.S. Простите за некропостинг, но вопрос интересный, полезный и ответ может пригодиться