Здравствуйте. Пытаюсь использовать PHP HTML DOM Parser для парсинга множества страниц: изначально около сотни, получаю через file_get_html, нахожу нужное и формирую ассоциативный массив в котором хранится сотня ссылок, далее снова через file_get_html пробегаюсь по массиву из этих ссылок и получаю еще сотню страниц, в каждой из которых нахожу по ~50 нужных мне строк.
В результате всё валится и требуются минуты, чтобы всё нормально получить.
В дополнение к остальным ораторам: вместо всяких дом-парсеров попробуйте использовать обычный preg_match_all и регулярки.
Ускорение будет в 10-100+ раз вероятней всего)
21 век... регулярки не то что бы совсем плохи, но поддерживать их и раньше было сложно, а сейчас данных и задач так много что просто не вариант. Проблема топикпастера в том что PHP плохо под такие задачи рассчитан, что бы использовать именно его надо много всего дописать, додумать, дорешать, дофантазировать и так далее... но классически задача решается так:
1. научитесь максимально быстро и просто получать данные с одной страницы
2. научитесь максимально прозрачно для себя и для приложения скачивать те страницы что вам нужны
3. научитесь организовывать предыдущие два пункта так что бы и нагрузка была распределённой и проблема парсинга одной страницы не убивала весь движок целиком
Парсеры штука интересная:)
Oleg Shevelev: php уже давно нормально подходит для парсинга и не нужно ничего из "много всего дописать, додумать, дорешать, дофантазировать и так далее".
то что топикстартер использует однопоточный допотопный парсер - проблема топикстартера, а не php.
DevMan: вы серьёзно? То что на нём можно написать что угодно ещё не значит что это не боль и страдания по сравнению с более подходящими решениями:) Вот несколько причин почему PHP это боль:
1. у PHP бездарное отношение к документации, в действительности почти никто не полагается на реальный код скрывающийся за функцией и "гуглит" решения в интернете и только в крайних случаях заглядывает в Си и смотрит что же там за входные/выходные данные могут быть
2. не возможность по нормальному обрабатывать ошибки, точнее возможность-то всегда была, кроме случаев обработки фаталов (с ними как было всё плохо так и остаётся), но тонны кода написаны абы как в этом понимании
3. не возможность нормального использования ресурсов, вы никогда не сможете гарантировать что ваше приложение медленно, но отработает, а не умрёт из-за нехватки памяти, переполнения стека, фантомных ошибок, сегментации и прочих особенностей которые могут всплывать в любом месте. Доступные функции для управления GB не сильно-то помогают, даже если вы будете сбрасывать GB после почти каждой операции - это вас особо не спасёт, разве что сделает код медленнее
4. медленная производительность при практически аналогичной сложности разработки например на Golang
5. всё совсем плохо если вы хотите написать многопоточный сервер на PHP, для этого не даром было написанно несколько дополнительных расширений на Си, что бы хоть как-то сгладить проблемы. Но в сухом остатке, если где-то хотя бы одна ваша функция упадёт в паник - весь сервер умрёт и вам нужно позаботиться об этом как-то дополнительно, а значит задействовать крон либо специальный софт который будет следить за сервером и перезапускать его. В любом случае - перезапуск по таким пустякам это плохая идея
6. множество накладных расходов буквально везде, когда у вас небольшой сайт - это нормально, когда у вас ферма серверов с разнообразными задачами то это не смешно и не интересно
7. если вам захочется модифицировать стандартную библиотеку, то использовать вы сможете её далеко не всегда и не везде, не всякому клиенту это подходит, да и не удобно
8. компетенция тех кто вам скорее всего будет пробовать помочь если у вас какая-то техническая проблема.
5. всё совсем плохо если вы хотите написать многопоточный сервер на PHP, для этого не даром было написанно несколько дополнительных расширений на Си, что бы хоть как-то сгладить проблемы. Но в сухом остатке, если где-то хотя бы одна ваша функция упадёт в паник - весь сервер умрёт и вам нужно позаботиться об этом как-то дополнительно, а значит задействовать крон либо специальный софт который будет следить за сервером и перезапускать его. В любом случае - перезапуск по таким пустякам это плохая идея
эээ. а зачем писать многопоточный сервер на php? php несколько для другого предназначен.
4. медленная производительность при практически аналогичной сложности разработки например на Golang
99% функционала упирается не в быстродействие языка. Оно упирается в data storage и политики консистентности. И вот тот кусочек логики(если он есть в проекте вообще) который критичен по быстродействию - действительно можно писать на чем угодно.
Но для всего остального я лично подхожу с точки зрения простоты поиска и замещения людей.
В мск PHP 11 300 резюме, java 6027, python 1576, ruby 638, Go 332.
Ответ очевиден. Какой бы Go не был распрекрасный, мне нафиг не нужен в проекте код, на который я потом задолбаюсь искать людей.
Создайте очередь задач ввиде простой таблицы в БД.
Напишите один скрипт который будет брать из таблицы адрес, скачивать, класть скаченное в папку и завершаться.
Напишите другой скрипт который скаченное будет разбирать, выделять ссылки и класть ссылки в таблицу для первого скрипта.
Запускайте каждый скрипт с помощью крона и небольшого bash скрипта N раз в минуту.
Средний
