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

[KillDead]

Здравствуйте. Хотелось бы узнать ответ на вопросы об этом инструменте парсинга. Да, в плюсы можно записать удобство и простоту.
А вот в минусы- Большая нагрузка на цп и проблемы очистки памяти. Интересует только при больших объёмах. Так как при малом- минусами можно спокойно пренебречь. Раньше был лишь небольшой опыт, тогда не нашёл решения проблем, почему память утекает, а процессор сходил с ума. Возможно сейчас чтото изменилось, костыли и решения появились.
В общем, если кто-то на больших объёмах пробовал пользоваться- отпишите об результатах. Стоит ли браться за него, или и дальше использовать простейшие альтернативы вроде preg_math и strpos

 

[nejtr0n]

Имхо, preg_match и strpos - не верные решения априори. Для парсинга XML есть SAX и DOMDocument. При парсинге очень больших XML можно использовать БД для хранения узлов. (Профит сомнительный, но в битриксе так делается. Лично тесты не проводил.) Опишите конкретней задачу: какие данные, уровни вложенности деревьев и тд.

 

[KillDead]

Спасибо за ответ, не верно поставил задачу- интересует парсинг сайтов - типо Для просмотра ссылки Войди или Зарегистрируйся .

 

[jDony]

Спасибо за ответ, не верно поставил задачу- интересует парсинг сайтов - типо Для просмотра ссылки Войди или Зарегистрируйся .

Язык принципиален? Для парсинга сайтов использую Для просмотра ссылки Войди или Зарегистрируйся (Для просмотра ссылки Войди или Зарегистрируйся).
Поддерживает очень много фич (кеширование, парсинг html, возможность парсить только новые данные). Довольно шустрая и простая в использовании вещь.

МИНУС - придется подтянуть Python.

 

[KillDead]

Язык принципиален? Для парсинга сайтов использую Для просмотра ссылки Войди или Зарегистрируйся (Для просмотра ссылки Войди или Зарегистрируйся).
Поддерживает очень много фич (кеширование, парсинг html, возможность парсить только новые данные). Довольно шустрая и простая в использовании вещь.

МИНУС - придется подтянуть Python.

да, язык пренципиален (Если бы не имел- было бы интересно вообще выбрать nodejs), предполагается на пхп. Именно там и проблема такая существует. На питоне был недавно бенчарк неплохой , именно инструментов- Для просмотра ссылки Войди или Зарегистрируйся

 

[jDony]

да, язык пренципиален (Если бы не имел- было бы интересно вообще выбрать nodejs), предполагается на пхп. Именно там и проблема такая существует. На питоне был недавно бенчарк неплохой , именно инструментов- Для просмотра ссылки Войди или Зарегистрируйся

Тогда уточните что вы понимаете под БОЛЬШИМИ объемами.

Выпаршивал большие порталы (видео\фото), сливал весь контент подчистую, делал на обычных регулярках, и не сталкивался в проблемами утечки памяти\загрузки цп.(на PHP конечно)
Опишите ТЗ подробнее и быть может тогда найдем решение проблемы.
Возможно вам не нужно будет менять инструмент(тот же DOMParser), а нужно будет просто изменить архитектуру проекта. Добавить очереди или разнести все это дело на несколько серверов. Так как под БОЛЬШИМИ объемами можно понимать что угодно.

 

[dwarf]

Выпаршивал большие порталы (видео\фото), сливал весь контент подчистую, делал на обычных регулярках, и не сталкивался в проблемами утечки памяти\загрузки цп.(на PHP конечно).

Соглашусь, что на PHP быстрее, чем регулярками html не распарить.
При использовании всяческих библиотек для парсинга всегда будет две проблемы - оверхед в использовании памяти и CPU + возможные проблемы с не валидным html.

 

[Alekc]

Я обычно использую DomDocument + xpath, никогда не встречался с проблемами памяти. Парсинг сайта а приори не должен давать проблемы т.к. не думаю что вам надо парсить страницу которая весит метров 50, а если проблема просто в кол-ве страниц то это уже другой вопрос, который обычно легко решается форсируя garbage collector.

 

[dwarf]

Я обычно использую DomDocument + xpath, никогда не встречался с проблемами памяти. Парсинг сайта а приори не должен давать проблемы т.к. не думаю что вам надо парсить страницу которая весит метров 50, а если проблема просто в кол-ве страниц то это уже другой вопрос, который обычно легко решается форсируя garbage collector.

Вам просто не довелось сталкиваться с проблемами утечек памяти в пхп. Циклические ссылки в сторонних библиотеках и вся эта рожь просто не дает возможности очистить полностью память после одной "итерации".

 

[KillDead]

страницу которая весит метров 50, а если проблема просто в кол-ве страниц то это уже другой вопрос, который обычно легко решается форсируя garbage collector.

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

Тогда уточните что вы понимаете под БОЛЬШИМИ объемами.

Выпаршивал большие порталы (видео\фото), сливал весь контент подчистую, делал на обычных регулярках, и не сталкивался в проблемами утечки памяти\загрузки цп.(на PHP конечно)

Ну так, на регулярках то и нет проблем ни с памятью, ни с быстродействием.

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