Search by WMSN

Лайфхаки для форумного доргена.
Получать контент с сайтов лучше не через foreach, а используя rollingcurl-класс
Автокрон без залипания - pastebin.com
Получать контент лучше через поднятие своего сервиса на отдельном сервере/впс используя простую либу php-boiler-pipe github.com

Answers:

Хуйня это )) причем тут foreach ? это просто цикл. и менять простой проверенный php curl на какой-то роллингкурл это вообще хз че за такое.

Mik Foxi, Ты просто его не пробовал. Это надстройка над классическим курлом, но он типа асинхронный. Т.е. парсинг будет идти не 60 секунд, а не более 10. Я например обрубаю соединение, если контента нет более 5 секунд.

уПопаБылаСобака, жжош. у нас пхп скрипт, он как бы в один поток идет, он быстрее не будет работать. а 2 пхп скрипта отдельно запущенных - это 2 потока и так. А CURLOPT_TIMEOUT я тож добавил во все.

Mik Foxi, Ты однозначно не в курсе, что курл бывает многопоточным.

уПопаБылаСобака, но php однопоточное. Как ты запустишь в одном php скрипте что-то многопоточно? )))

Mik Foxi, Вопросы не ко мне github.com

Mik Foxi, ну так скрипт запрашивает разу n соединений, не дожидаясь ответа от них. А потом по факту прихода данных - обрабатывает отдельно...Типа Rolling Curl. Парсится все в n раз быстрее...

doorwaymoney, почитал, понял что они считают что все тупые, и юзеры и другие курлы и мультикурлы )))) при поверхностном рассмотрение врятли оно сделает заметное ускорение.

уПопаБылаСобака, можешь мне скинуть пример твоего кода, который стал супер ускоренным? )

Можешь и этот поизучать php.net мультикурл без всяких оберток.

Mik Foxi, Когда требуется спарсить 1 лям урлов, на много быстрее. Если просто тупо обходить курлом, допустим страница отдается в среднем за 7 секунд, получается 7 лямов секунд, или 81 день Запускаем то же самое но через rolling curl или аналог, на 20 потоков допустим, и допустим что 20 потоков не убивает сервер. Получаем 20 запросов за тех же 7 секунд. То есть уже речь идет о 350 тыс. секундах. Ставим поток 50, и уже остается 140 тыс секунд, или 2-ое суток, взамен 81....

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

doorwaymoney, тем более что надобности ускорять парсинг нету. во много потоков все равно не пустишь наполнение, база повиснет.

Mik Foxi, Если процес заканчивает свою работу бестрее в n-раз, как думаешь, нагрузка на проц будет падать?

уПопаБылаСобака, когда одновременно куча процессов - нагрузка на проц и память будет расти. Если ты правильно все сделал, то скорость улучшишь, но нагрузку на проц и оперативку ты тоже увеличишь, а это не гуд.

Mik Foxi, Ну тут такой момент.Допустим на страницу выводится текст скомпилированный из 7 источников. На каждый источник 2-3 секунды (ожидание от сервера), получается время генерации страницы 14-21 сек. Что есть много. Если источники опрашиваются одновременно, то будет 2-3 сек. Но тут еще влияет макс. время ожидания. Если один источник подвис, то будет условно 10 сек, в случае мульти запросов, или более 20 сек в случае последовательных.