Задача: Парсинг поисковой выдачи Google. Условия: Скорость: от 5 000 запросов в час. Глубина: ТОП 100 (не важно, 1 страница и 100 результатов или 10 страниц по 10 результатов) Софт: A-Parser (1.2.1794) + Xevil 6 (Beta 21) Что сейчас: До 2023, всё работало стабильно, использовались прокси A-parser, проблем не возникало. Сейчас уходят в бан или в цикл проверки (рекапча => капча => рекапча => и в бесконечный повтор до 429 кода ошибки и фактически бана). Перепробовал десятки прокси. Ситуация схожая. Вопросы: 1) Проблема в прокси? (Посоветуйте, какими пользуетесь?) 2) Пробка в настройках? (Какие настройки используете?) 3) Проблема в синхронизации между A-Parser + Xevil? (на форуме Xevil, разработчики пишут, что связка hrefer + Xevil работает стабильно) Решение: Возможно реализовать? Нашел темы на форуме: от 28..07.2022 - https://a-parser.com/threads/7593/ от 03.07.2022 - https://a-parser.com/threads/7489/page-3 Далее 03.09.2022, вышло обновление - https://a-parser.com/threads/7671/#post-24524 Но кажется, что проблема не решена.
Действительно в последнее время такая проблема наблюдается в апарсере с парсингом на больших объемах. Тоже тестировали на разных прокси. Зацикливание с капчей и 429 ошибка значительно уменьшается если в настройках убрать - Location (City). Но, тогда точность/правильность выдачи уменьшается.
На данный момент актуальная инструкция для парсинга Google при использовании Xevil: В Xevil: Тип апи: Antigate (Anti-Captcha) Включен прием прокси, кук и юа Подключены прокси (не те, что в парсере) В A-Parser: В настройках рекаптчи Provider - Xevil (Antigate) В настройках гугла - 10*10, ReCaptcha2 pass proxy выключено Ну и выбран пресет рекаптчи Остальное все по дефолту Прокси в парсере наши Работает нормально, токены гуглом чаще принимаются, чем не принимаются (статистики нет, визуально по логу где-то 70% принимаются). Если включить ReCaptcha2 pass proxy, то в ксевил будет передаваться прокся из парсера. Но если она в процессе умрет, то ксевил возмет из тех, которые к нему подключены. А если нет подключенных, то будет пытаться гадать рекаптчу без прокси Пробовали и с включенным ReCaptcha2 pass proxy, разницы не заметили
Тест парсинга Google Условия теста: парсинг топ100 из поисковой выдачи Google, время парсинга - 10 минут. Цель теста: сравнить различные условия парсинга. Для теста были использованы: A-Parser 1.2.1798 прокси из Личного кабинета, 50 потоков, все остальное по дефолту, кроме того, что указано ниже для каждого отдельного теста. XEvil 6 [Beta-22] в соответствии с рекомендациями из форума: тип API - Antigate (Anti-Captcha), включен прием прокси, кук и юзер-агента, подключены прокси (не те, которые используются в А-Парсере). 1 стр, 100 рез/стр, 30 попыток, разгадывание рекаптчи через anti-captcha - скорость 13 запросов/минуту Спойлер: Скриншот 10 стр, 10 рез/стр, 30 попыток, разгадывание рекаптчи через anti-captcha - скорость 20 запросов/минуту Спойлер: Скриншот 1 стр, 100 рез/стр, 100 попыток, без разгадывания рекаптчи - скорость 24 запросов/минуту Спойлер: Скриншот 10 стр, 10 рез/стр, 100 попыток, без разгадывания рекаптчи - скорость 6 запросов/минуту Спойлер: Скриншот 10 стр, 10 рез/стр, 30 попыток, разгадывание рекаптчи через XEvil - скорость 12 запросов/минуту Спойлер: Скриншот 10 стр, 10 рез/стр, 30 попыток, разгадывание рекаптчи через XEvil, включен ReCaptcha2 pass proxy - скорость 13 запросов/минуту Спойлер: Скриншот 1 стр, 100 рез/стр, 30 попыток, разгадывание рекаптчи через XEvil - скорость 2 запроса/минуту Спойлер: Скриншот 1 стр, 100 рез/стр, 30 попыток, разгадывание рекаптчи через XEvil, включен ReCaptcha2 pass proxy - скорость 1 запрос/минуту Спойлер: Скриншот Вывод Наибольшая скорость достигается при парсинге 1*100 без разгадывания рекаптчи (на попытках). Если говорить о разгадывании рекаптч с помощью XEvil, то лучше всего парсить 10*10. Но скорость будет ниже, чем при разгадывании через anti-captcha, т.к. токены от XEvil намного хуже принимаются Гуглом и соответственно выдается намного больше повторных рекаптч. Передача прокси в XEvil (ReCaptcha2 pass proxy) практически не влияет на скорость.
1. 300-500 запросов собрать можно даже на самых плохих проксях, интересно посмотреть как будет идти сбор после 15000 запроса 2. На 3 скриншоте уже на 249 запросе у вас пошли неудачные на 4 скринштое уже на 64 запросе у вас пошли неудачные!!!
Нормально все и после 20к собирает) (10 результатов по 5 страниц). Главное понять логику работы с рекапчей и подобрать под это пул прокси. Хочешь парсить по 100 резалтов на норм скорости, есть прокси с новым IP каждый запрос, но там 1 поток 700р стоит. Бери их и будешь летать )
Вот всегда удивляли такие бессодержательные ответы, разве что для накрутки постов... "понять логику работы с рекапчей" - если вы её действительно понимаете, то поделитесь с сообществом своими знаниями применительно к парсингу серпа гугла (здесь обсуждаем именно это). "Хочешь парсить по 100 резалтов на норм скорости, есть прокси с новым IP каждый запрос, но там 1 поток 700р стоит. Бери их и будешь летать" - что для вас нормальная скорость? По проксям - без разницы, какие прокси, если вы используете их для парса без ротации, закапчиваются они все, в том числе и самые элитные и индивидуальные. По скрину как-то вот сложно комментировать - там google position. Понятно, что там используется SE::Google, но будем корректными, мы обсуждаем не SE::Google:osition. Текущая проблема тянется с лета, написано по ней очень много, и не стоит отвлекать внимание, если нечего сказать.
Просто в тесте мало попыток поставил, на саму суть это мало влияет. 1*100, 500 попыток, без разгадывания
Всегда удивляли такие душнилы, у которых если не знает чего-то, то этого не существует. Специально для таких SE::Google 10 по 10. И конечно же никакой больше инфы) Да и саппорт все расписал понятно. И если непонятна фраза "прокси с новым IP на каждый запрос" тоже помочь ничем не могу)
Правильный делаю вывод? 1) Используем прокси a-parser 2) Ставим кол-во попыток 500 3) Парсинг 1*100 4) В настройках парсера, ставлю пресеты для Recaptha 2, Anti-Gate: default
Если планируете парсить на попытках, то разгадывание рекаптчи не обязательно подключать. Если же планируете подключать разгадывание рекаптчи, то кол-во попыток можно задать меньшее. Насчет оптимального способа парсинга - лучше всего потестировать самостоятельно и выбрать наиболее оптимальный в вашей конкретной ситуации
Версия: 1.2.1853 Прокси: A-parser Метод: Без антикапччи, перебор прокси. На прошлой неделе % ошибок увеличился до 95%. Способ перестал работать. Есть ещё возможности для парсинга Google?
Версия: 1.2.1872 Прокси: A-Parser (пробовал различные ipv6, ещё хуже) Метод: Без антикпчи, увеличил перебор прокси до 200 попыток. Увеличил время бана прокси для парсера. Уменьшило % ошибок (до 30%), но снимать стало ооочень долго. 40 000 запросов 2-3 дня снимает. У кого получилось настроить парсинг Google?
Версия 1.2.1876, прокси из ЛК, 300 потоков, кол-во результатов 1*100, 500 попыток, все остальное по дефолту. Как видно на скриншоте, средняя скорость 267 запросов в минуту, соответственно 40к запросов при такой скорости будут обработаны за 2-3 часа. ,
Я не знаю, виновен ли гугл. Но я был свидетелем, как обвал парсинга гугла начался с одной из обнов. Мои напарники, с которыми я паршу гугл пожаловались примерно одновременно, что с января-февраля гугл стало невозможно парсить. А я изменений в скорости вообще тогда не заметил. Тогда начали сравнивать настройки и оказалось, что разница была только в версиях парсера (у меня была более старая 1.2.1662). Товарищ подключал мою версию на своем железе и скорость была нормальной. У него скорость была раза в 4-5 ниже. Когда начали общаться с саппортом на эту тему и они начали тестить, немного упала скорость на старой версии, но на новых было без изменений.
Подтверждаю наличие этой проблемы, пробовали на версии ещё более ранней 1.2.1646, скорость парсинга гугла чуть ли в 10 раз выше, чем в самой последней на этот момент бете 1.2.1895. Саппорт ответил, что о проблеме знают, работают над этим, но пока нет решения. Понимаю, что это очень противоречиво и сопряжено с трудностями, но надо бы всё же придумать, как реализовать ветку обновлений старых версий для таких случаев, когда можно внести мелкие изменения в регулярное выражение (за это время верстка гугла поменялась) и продолжать работу без потерь времени и средств у пользователей, ожидая, когда разработчикам удастся справится с проблемой.
А с чем может быть связано снижение Скорости? На скриншоте Скорость текущая/Общая: 333/267. На 100 потоков скорость 6/7.
Добрый день, Рекомендую по поводу скорости ознакомиться со статьей - https://a-parser.com/resources/404/
Спасибо, изучил. Там ответа на вопрос не нашел. Указаны 3 причины, мне не подходят. 1) Ресурсы. С ними всё ок, машина холодная. 2) Скорость зависит от конкретной страницы. Парсим схожие выдачи. 3) Скорость зависит от парсера. Используем одинаковый парсер SE: Google
