Пути обхода временного бана Google за частые обращения к базе

*Гостевой пост

Этот пост посвящен особенностям работы со скриптом nTrendsMaster, массовой проверке выдачи Google на предмет количества конкурентов по нужным запросам и проблеме тайм-аута со стороны Google вообще. Пост очень хорош в плане расширения кругозора (я о многих написанных здесь вещах раньше и понятия не имел 🙂 ) и в некотором роде объясняет причины проблем, которые могут возникнуть у вас во время использования заточенных под Google скриптов и программ (в том числе и Market Samurai).

Пост представляет собой компиляцию из комментариев и переписки с Интернет-предпринимателем Олегом Савченко и публикуется с его разрешения.

—————

Расклад такой (у меня во всяком случае):

  • запускаем скрипт и даем ему 100-200 слов – все отрабатывает без проблем…
  • запускаем его еще раз с таким же количеством… и еще… если не выдерживать между запусками паузу хотя бы в полчаса, то буквально после 3 запусков (то есть после 400-600 проверенных слов) лезут ошибки по проверке конкурентных страниц ;-((

После того как я тут же пробую искать что-то в гугле, я вижу капчу. Скрипт запускался с Денвера, поэтому капча говорит о том, что мой айпишник на время попал в бан. То есть в ручном режиме я могу ввести код этой картинки дальше какое-то время спокойно пользоваться гуглом. Но в течение еще примерно 5-6 часов эта самая капча может рандомно появляться при любых моих обращениях к Гуглю (а может и не появляться). В любом случае в это время использовать скрипт с этого же адреса не получится, ибо он ни картинку распознать, ни вбить код не сумеет…

Какие я вижу пути решения:

1. Увеличение пауз между запросами к гуглю в скрипте. Но не просто увеличение пауз, а еще и их рандомизация. Многие десктопные приложения (KRA PRO, IBP и другие) не попадают под бан гугля именно поэтому. Однако они ставят между каждым запросом от 7 до 30 секунд перерыва!!! Если просто ставить 5 (7, 10, 15) секунд и все паузы делать одинаковыми, гугль все-равно просекает автоматизацию и выдает капчу ;-((

Чем плох этот путь? Тем что время на проверку скриптом становится сопоставимым со временем на проверку вручную. Но есть и плюсы: ты в это время все равно занимаешься не проверкой, а чем-то другим. Получается “долго, но без тебя”, поэтому вариант имеет право на существование. К сожалению, иногда он все-таки дает сбой. Возможно, потому, что я курлом (функция такая curl в PHP) дергаю страницы, а, может, надо больше под браузер косить (есть и такие библиотеки, которые более-менее точно позволяют эмулировать браузер). Короче, тут есть еще над чем подумать…

2. Использование ключей от гугли. Но проблема здесь в том, что гугль официально больше не поддерживает SOAP API, а всем рекомендует переходить на AJAX API. Я заметил, что результаты в этом случае сильно отличаются от поиска в ручном режиме (в разы, а то и в десятки раз!!!). Вот тут (http://www.google.com/search?hl=en&safe=off&q=ajax+google+api+estimatedResultCount) вы увидите что эта проблема повсеместная… Так что новый API использовать в целях каких-либо SEO исследований крайне не рекомендую.

Что касается старого метода, с использованием Google SOAP Search API, то тут все хорошо: результаты расходятся “в пределах разумного” (на разных гугловых серверах они также расходятся, так что все ОК). НО! Гугль больше не выдает пользователям эти самые “старые” API-шные ключики. А значит написать скрипт, который будет публичным, попросту невозможно.

Народ просек разницу между старыми и новыми ключиками и кинулся старыми торговать… А я еще удивлялся — кому они нужны по 25$-то??? Но вот на forums.digitalpoint.com им именно такая цена назначена. А с одного ключика только 1000 запросов в день можно сделать. У них такой лимит всегда был. То есть, владея одним ключом и скриптом, на базу из 10 000 нужно потратить 10 дней. Ну или купить 10 ключей, но овчинка выделки не стоит. Бесплатный скрипт, который для работы требует дополнительных 250$ на собственные ключики – это не серьезно…

Впрочем, тем у кого подобно мне есть старые запасы ключей – имеет смысл обратить внимание на такую возможность. Но это никак не для паблик-релиза… Увы…

К тому же, покупка в онлайне не гарантирует того, что одновременно с тобой этот же самый ключик у того же продавца не купило еще пара десятков покупателей ;-)) и тогда этот ключ становится вообще бесполезным. То есть покупать надо только у проверенных лиц, которые могут гарантировать уникальность продажи. А где же их взять-то?

3. Сочетание первого с работой через прокси. Можно создать несколько одновременных потоков (с разных прокси, т.е. с разных айпи-адресов, они будут приходить на гугль), каждый из которых будет выдерживать разумные паузы и тогда скорость работы всего скрипта увеличится во столько раз, сколько этих самых потоков будет задействовано. Здесь сложность заключается в поиске РАБОТАЮЩИХ и при этом действительно АНОНИМНЫХ прокси, которые бы точно не светили настоящий айпишник перед гуглем. Среди десятков, сотен, а то и тысяч бесплатно доступных списков прокси в интернете после проверки остаются рабочими доли процента. Вот вчера проверял специальной софтинкй более 2000 прокси — работало только около сотни, а анонимными было штук 20… То есть скрипт надо еще оборудовать и такой составляющей, как граббинг списков проксей и их регулярную проверку на работоспособность. А это уже отдельный монстр получается. Я такие работающие системы знаю, даже использую платный скрипт, а вот интегрировать его в этот скрипт напрямую не удастся — только через импорт-экспорт. Впрочем, эта проблема решается, но опять же о массовости использования в этом случае можно забыть. К чему я это все? К тому, что сделать скрипт “для себя” вполне реально. Только нужен свой собственный прокси-чекер или купленные прокси. И то и другое стоит денег.

4. Вариант “для маньяков”. Приобретается 5-6 хостингов с работающими открытыми соединениями для PHP-скриптов (не каждый хостинг это позволяет, т.е. сами скрипты на PHP сейчас повсеместно доступны, а вот чтобы этим скриптам была открыта “дорога” на установку соединений с внешними серверами, это далеко не у всех). Но найти таких провайдеров вполне реально. Затем пишется скрипт, который задание, скажем, из 1000 слов разбивает на 5 порций по 200 и раскидывает на 5 хостингов, где они спокойно в обычном режиме без всяких переделок проверяются. Ведь по 200 слов обычно все проходит… А потом они результаты скидывают обратно в этот “центральный” скрипт, который тебе и выдает объединенную картинку. Это как бы и прокси, и не прокси одновременно 😉 Но цена 5 хостингов – сами понимаете… причем ежемесячно… Проще купить прокси-чекер и с Денвера все запускать…

5. Использование данных от Wordtracker или другого подобного сервиса. У них обычно Competitors довольно близки к данным гугли по США. Популярность ключевых слов нас не интересует, тут нам гугльтрендс в помощь, только данные о конкурентах… Но, опять же, финансовая сторона вопроса…

Вот такой расклад. Я склоняюсь к последнему. То есть в самом скрипте выключить нафиг проверку конкурентов. А прогонять все на поиск нужного количества запросов. И уже “отсеянное” (отбрасываем все, что ищут слишком редко или слишком часто) отправлять на проверку конкурентов. Единственное, что в этом случае получается многоходовая комбинация, а хотелось бы “все и сразу”, но пока этот вариант мне кажется довольно привлекательным (учитывая то, что подписку на вордтрекер или любой другой аналогичный сервис все равно желательно иметь). Но если вордтрекер не по карману – тогда варианты выстраиваются так:

  • со старыми ключами (не для всех подходит);
  • с прокси и многопоточным выполнением запросов (сложно в изготовлении, но реально);
  • с несколькими хостингами (цена может быть сопоставима с ценой вордтрекера).

Записи по теме:

Нравятся статьи? Подписывайтесь на рассылку!

1 Star2 Stars3 Stars4 Stars5 Stars (Пока оценок нет)
loadingЗагрузка...
Логотип сайта

32 комментария

  1. Забыл написать, вариант с несколькими IP прекрасно “танцует”, если хостер выделяет под каждый домен свой IP, такой вариант очень редко встречает на шаред хостингах, но в принципе, он возможен. И второй вариант, когда вы сами купили IP под какие-либо домены, потому что вам на них понадобились анонимные фтп, то вполне эти IP использовать под наши цели.

    PS. Вы меня опять не правильно поняли, я вас не агитирую на использование нескольких IP, я просто пытался вам показать что технически это легко можно сделать. Лично я за вариант, с вводом капчи, но похоже он тоже вам не нравится, хотя для бесплатного скрипта, это как раз то что нужно.

  2. Ок, согласен, принято к рассмотрению. Есть у меня сервер с пятью айпишниками – попробуем-с…
    Насчет капчи – этот вариант подходит для так называемого “полуавтоматического” парсинга, когда вы постоянно присутствуете и следите за работой скрипта и вводите капчу когда надо. А если скрипт работает удаленно и просто пишет все в лог? А если вы запустили скрипт на ночь и пошли спать, в надежде что утром у вас будет большой объем данных для творческого осмысления, а скрипт остановился на капче через пол-часа и всю ночь простоял?
    так что капча “в топку” – ее просто не надо допускать. D@nil выступает за прокси, вы с MegaS’ом за покупные айпи – эти варианты и будем рассматривать. По таким критериям как общедоступность, легкость в настройке и ипользовании, гарантия от бана (кстати тут прокси предпочтительней на мой взгляд), работоспособность (вот тут ваш вариант может дать фору проксям, ибо они обычно тормозят). Ну и вопрос цена/производительность остается актуальным. Тут звучала цифра в 25000 поисков в сутки. В зависимости от того, сколько понадобится этих самых прокси и айпишников для гарантированного многообразия и непопадания в бан. При заданной общей производительности. В любом случае уже думаю всем ясно, что совсем бесплатно этого не достичь – так что поднимаем планку и рассматриваем платные варианты. Тут прокси выгоднее, так как скрипт чекера покупается один раз, а за дополнительные адреса надо платить. но… будем проверять…

  3. Да вариант с капчей полуавтоматический, но если рассматривать скрипт именно для начинающих, то он предпочтительней, т.к. он не требует никаких дополнительных затрат, даже собственного хостинга :), т.к. вполне достаточно денвера. Кстати капчу всё равно надо бы отслеживать, даже если её не вводить, для того чтобы если появилась капча, не долбить гугл ненужными запросами и выдать информацию об увеличении времени задержки.

    И ещё один момент, если появилась капча при работе скрипта, то просто так вы её не снимете, если даже введёте её в браузере, скрипт всё равно дальше не заработает из-за юзер агента, т.е. разбанится только тот браузер, где была введена капча. Это по моему опыту работы, может это и не во всех случаях, не знаю.

    В принципе, вариант который вы описывали выше, сначала проверить на конкуренцию (было бы неплохо здесь ещё проверку для yahoo добавить, чтобы не было случаев, как описывал profithunter, сначало ссылок несколько десятков тысяч, а через 2 недели несколько миллионов), а затем прогнать через гугль тренд, является оптимальным, если поставить довольно большую задержку, то с одного IP и в один поток (если не использовать юзер агент), можно прогнать тысяч 10-20 за сутки при средней задержке в 4-8 секунд. В этом случае и капча не нужна.

  4. Я как раз сейчас проверяю именно величины этих “допустимых” пауз и их рандомизацию. Это требует времени, так как при каждом пропущенном бане ребуется время на восстановление работоспособности. Если приближаться к этому допустимому порогу “снизу”. Если же идти к нему “сверху”, то есть брать заведомо разрешенные большие паузы и постепенно их снижать, то сейчас у меня работает один вариант с рандомными паузами от 6 до 10 секунд и периодической вставкой между каждыми 20-30 запросами (рандомной же) еще одной дополнительной паузой от 6 до 13 секунд. То есть при самом “долгом” варианте это будет:
    – пауза в 13 секунд после каждого 20-го запроса
    – пауза в 20 секунд между самими запросами
    Итого на 20 запросов (без учета времени одидания ответов сервера) будет тратиться 413 секунд. При работе с Денвера время ответа от Гугля у меня выходит еще по 2-3 секунды на запрос. В целом мы имеем 473 секунды в самом худшем случае. То есть порядка 3 запросов в минуту. Это уже быстрее чем в ручном режиме проверки (ведь вручную надо обратиться как минимум два раза к гуглу и два раза к гугл-трендсу на каждый один кейворд – то есть 13 запросов в минуту сделать не каждый сможет, а делать их безошибочно на протяжении сачов – и подавно). Но еще пока недостаточно быстро. Ведь в сутки пока выходит реально проверить только около 4500 кейвордов. Но это уже что-то. И абсолютно бесплатно. Но вот удастся ли снизить общие паузы в два с лишним раза, чтобы выйти на 10000 в один поток и без бана – это вопрос времени. Даже если снизить их в полтора раза, то 6-7 тысяч с одного Денвера тоже весьма неплохо. А дальше каждый такой поток “тиражируем” одним из обсуждаемых тут способом (да и скорость отклика Гугла на сервере будет гораздо меньше чем при работе Денвера на локальном компе). Так что общая заявленная выше планка в 25000 в сутки технически абсолютно не проблематична. Если для этого понадобятся “всего” 4-5 потоков, то она будет и довольно низкобюджетна.

  5. 4-ый вариант – это криво реализованные свои прокси:) проще и лучше на этих хостингах прокси-серверы поднять

  6. Coast dresses of 2011 summer full of vitality and color. This is your wardrobe an instant update of all those signals through the main trends for the coming occassion dresses 2011. From the luxurious fabrics, these basic essential pieces of the season will be a treasure you will relive for years. Coast dress into a modern urban women . Cheap coast clothing on sale, which is well known for their style and synchronized with the latest fashion trends.

Добавить комментарий для evgen Отменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Получать новые комментарии по электронной почте. Вы можете подписатьсяi без комментирования.

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.