Поможет ли моем случает multi_curl улучить быстродействие и какие есть пути оптимизации парсинга?

Question

[Евгений]

Здравствуйте,

Имеется сервер с большим количеством IP адресов и небольшой скрипт-парсер на PHP 7. Так же есть несколько интернет-магазинов с огромным ассортиментом, ~ 15000 позиций, одна позиция = одна страница. При заходе посетителя на страницу товара, если в кеше нет актуальных данных, отправляется запрос на парсер, он его обрабатывает и возвращает результат, который кешируется на 30 мин.

Собственно сам скрипт-парсер незамысловат. Получем ID товара, парсим с помощью curl требуемую информацию и возвращаем. В данный момент сервер парсинга со своей задачей справляется, но не покидает мысль, что его работу можно как-то оптимизировать. Видел примеры с multi_curl, но там идет работа с уже имеющимся, сформированным списком адресов по которому идет распараллеливание работы. Видел пример с Pthreads, по-моему, это тоже не то. Уважаемые знатоки, а какие еще методы оптимизации быстродействия можно провести? :)

Answer 1

[Андрей Николаев]

А вы не пробовали это делать не по запросу пользователя (заходу на страницу) а фоновый скрипт, который сам бы проверял актуальность и уже запрашивал данные с стороннего сервера?

Я вижу следующее узкое место:
Предположим на сайт зайдет одновременно 100 пользователей и все направят свои запросы к одной/разным страницам, данные по которым уже истекли. Вы отправите 100 запросов на внешний сервер, а потом 100 раз обновите данные в кеше? А если сервис увеличит таймаут? Ну, например до 0.5 секунд на запрос и вы забьете полностью ваш интеренет канал?

Предлагаемый вариант:
Вы получаете страницу и сохраняете ее в кеше, допустим на 1 сутки и пишет данные по expired на 30минут/1час. Фоновый скрипт, проверяет актуальность данных страниц 1 раз в 30 минут/1 час и если страница обновилась(!) - обновляет данные, обновляя кеш и увеличивая expired. В этом скрипте Вы можете применить и мульти-curl и потоки/процессы и все что хотите для ускорения (хоть на go пишите). Если так получилось, что скрипт по какой-то причине не добрался до страницы на 1 сутки, то скрипт отправляет соответствующее уведомление администратору и вручную тянет страницу как в предыдущем случае (и все так же сохраняет в кеше).

В таком случае, сколько бы пользователей не зашло на страницу, они всегда будут видеть актуальные данные, а в корявом случае - вы всегда получите fallback к текущей версии и тут уже нужно будет разбираться в чем причина (в идеале случай с отвалившимся фоновым скриптом не должен вообще наступить, но если он произойдет - есть falback)

Answer 2

[xmoonlight]

Уважаемые знатоки, а какие еще методы оптимизации быстродействия можно провести?

1. Можно оптимизировать парсинг для бэкграунд режима на основе предсказания. Т.е. если запросили товар с определёнными характеристиками, то все линки с этим товаром для всех магазинов - ставим в приоритет!

2. Используйте круговую очерёдность доменов (round-robin) при обработке урлов из очереди, чтобы увеличить интервалы между запросами к одному сайту и тем самым, уменьшить риск бана.

3. Создайте API для своего сервиса, к которому будут подключаться клиенты, а в клиентах - сделайте возможность получения информации о товарных предложениях с других сайтов минуя Ваш сервер (только это укажите явно!). Т.е., превратите клиентов в прайс-консолидаторы. Таким образом, Вы распределите нагрузку парсинга среди клиентов. А когда клиенты будут собирать информацию по конкретному товару сразу с нескольких URL - пусть автоматически отсылается информация через API на ваш сервер.

4. (всё нижеописанное - для одного домена, который необходимо парсить!)
Периодичность парсинга для конкретного магазина - зависит только от ширины вашего канала, вычислительных мощностей на вашей стороне и соблюдения АДЕКВАТНОГО интервала между последовательными запросами к этому (одному) магазину. Т.е. при "round-robin" следите, чтобы запросы были не чаще, чем раз в 5-10 минут.

Или можно просто чередовать "пакет"/"период":
"пакет": 100 запросов с периодом 2 минуты и пауза 3 часа,
"период": 100 запросов на протяжении 3-х часов, и снова "пакет",
и т.д. по-кругу (или в случайной последовательности).