*Гостевой пост
Этот пост посвящен особенностям работы со скриптом 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 довольно близки к данным гугли по США. Популярность ключевых слов нас не интересует, тут нам гугльтрендс в помощь, только данные о конкурентах… Но, опять же, финансовая сторона вопроса…
Вот такой расклад. Я склоняюсь к последнему. То есть в самом скрипте выключить нафиг проверку конкурентов. А прогонять все на поиск нужного количества запросов. И уже “отсеянное” (отбрасываем все, что ищут слишком редко или слишком часто) отправлять на проверку конкурентов. Единственное, что в этом случае получается многоходовая комбинация, а хотелось бы “все и сразу”, но пока этот вариант мне кажется довольно привлекательным (учитывая то, что подписку на вордтрекер или любой другой аналогичный сервис все равно желательно иметь). Но если вордтрекер не по карману – тогда варианты выстраиваются так:
- со старыми ключами (не для всех подходит);
- с прокси и многопоточным выполнением запросов (сложно в изготовлении, но реально);
- с несколькими хостингами (цена может быть сопоставима с ценой вордтрекера).
Записи по теме:
- Вся правда о клоакинге
- Как быстро узнать о взломе блога
- Как Profit Hunter чек обналичивал
- Увеличение конверсии Интернет-магазина
Загрузка...
Самый нормальный вариант, это отлавливать в скрипте необходимость ввода капчи, предлагать её ввести через скрипт, т.е. картинку при этом качать в самом скрипте и отправлять гуглю результат ввода капчи и нормально работать дальше, до следующей капчи. Этот вариант, хотя и не удобнее варианта с проксями, но значительно проще реализовать совместно с 1 пунктом.
А в качестве 4 варианта, вполне можно использовать бесплатные хостинги с поддержкой PHP, единственно проблема, что curl’а там может не быть, так что хостинг придётся ещё поискать.
4-ый вариант – это криво реализованные свои прокси:) проще и лучше на этих хостингах прокси-серверы поднять
По сабжу проблема актуальная, тоже гугл парсю, сам обхожу просто – покупаю десятки айпи (20-30) на сервера, с которых парсится + незначительный таймаут. Для разумных объемов – около 10к разнообразных запросов в том числе: выдача по ключевикам, беки, пейджранк – работает на ура
пс скоро буду комментатор №1 🙂
to MegaS…
Тут ты не совсем прав…
Прокси фактически любой нормальный хостер вычисляет на “раз-два-три” и тебе придется общаться с их “секьюрити офицер” и объяснять что за скрипт такой ты поставил. Или кто-то умный из любителей фришных проксей отсканирует сетку и найдет твои прокси. В любом случае скорее всего с тобой никто общаться не будет – просто прикроют аккаунт и все. А вариант “кривых прокси” мною уже опробован на довольно известном хостере 3fn.net и прекрасно работает, и не нагружает самого хостера. А так как это все же не прокси – то и при сканировании портов его нет, а закрыть GET или POST запрос к этому скрипту паролем ничего не стоит.
К тому же, если говорить про “кривые” прокси и про “прямые” – в любом случае нужен некий многопоточный вариант или некий центральный менеджер, раздающий задачи. Вот его реализовать грамотно не сложно, но все же гораздо сложнее чем найти нескольких хостеров с работающими наружу CURL’ами.
В данный момент я знаю двоих таких хостеров, просто больше не искал. Ибо в том же 3fn.net спокойно можно взять 3-4-5 аккаунтов на серверах расположенных В РАЗНЫХ подсетях класса C, что будет выглядеть точно также, как разные аккаунты у разных хостеров. Даже больше того – есть много “хостеров” которые всего лишь реселлеры, и могут базироваться реально на одном сервере или одной подсетке – в этом случае “разные айпишники” будут для гугля все-равно “не разными” 😉 Это будет выглядеть как из одного компьютерного класса идет волна запросов – то есть айпишники вроде разные, но “рядом”, а это не есть гуд.
Теперь по поводу покупки десятков айпи на сервера… Верю на слово, но немного сомневаюсь. Дело в том, что обычная практика в настройке серверов заключается в том, что снаружи-то к ним можно обращаться по разным айпи, но реально эти адреса будут приходить на одну-две-три сетевые карточки (ну сколько их в сервер воткнуть можно? даже если они каждая многопортовая?).
Тут дело в том, что определенная сложность настроек (и лень администраторов) приводит к тому, что “прийти” к серверу можно с разных айпи, а вот обращения “от сервера” куда-то наружу обычно идут с одного и того же адреса. Реально настроить так, чтобы скрипты обращались от сервака к гуглю с разных айпишников можно, но сомневаюсь чтобы хостер об этом позаботился 😉 Ну 2-3 адреса он сделал, так сказать для резервирования или для распределения нагрузки на каналы. Но чтобы десятки!!! тут сомневаюсь…
Но повторяю, все может быть…
Однако если ты внимательно читал – речь еще и о деньгах шла. Насколько мне известно айпишники идут от 0.5$ до 1$. 20-30 айпишников это будет до 30 долларов. О какой бесплатности тогда идет речь? 30 долларов это реальные 6 аккаунтов на 3fn.net в реально разных подсетках со 100% гарантией от попадания в засвет перед гуглем. 30 долларов – это цена хорошего прокси-чекера. Причем разовая, а не помесячная. 30 долларов, это стоимость неплохого VPS-сервера, на котором это прокси-чекер можно поставить и тогда работать спокойно без боязни что айпишники на сервере как-то не так сработают из -за сисадминской лени. В конце концов 30 долларов – это больше ежемесячной стоимости вордтрекера, если его брать на год, то в месяц выйдет всего по 27$ 😉
При всех приведенных математических выкладках возникает вопрос – чем твой вариант лучше? И если не секрет, то как же твои 20-30 айпишников используются для парсинга? В один поток “по кругу” обходятся или как? Один скрипт на одном сервере при всем желании не сможет работать с разными айпи, даже если сервер ПРАВИЛЬНО настроен. Просто потому, что этот самый скрипт одновременно может выполняться только одним интерпретатором PHP, который, естественно, не имеет ни малейшего понятия, что твои запросы к гуглю надо по каким-то айпишникам раскидывать…
Так что реальный вариант только один – центральная часть, она же менеджер заданий, которая раскидывает задачи по нескольким отдельным потокам, при этом эти потоки должны быть отдельными скриптами на отдельных “серверах” (если используются прокси, то они как раз такими скриптами и будут, если не используются – надо делать свои “кривые”). Значит ты еще и 20-30 доменов под это дело покупаешь? Тогда цена вопроса еще больше выростает…
В общем – что-то тут не так. Буду признателен, если напишешь мне ответы не сюда, а по форме обратной связи на моем сайте (не пугайся, сайт несколько заброшен, так что не взыщи, просто тут мыло светить не охота, боты тоже бегают здесь 😉
Давай просто не будем дальше путать и без того запутавшуюся молодежь, читающую этот блог? Свяжешься? Заранее благодарен!
Если бы в скрипте не нужно было логиниться в учетную запись, можно было бы просто с одного IP-шника работать подставляя различные User-Agent, т.к. Гугль банит не только по IP, он в том числе ещё проверяет User-Agent, по-крайней мере так работает поиск.
Забыл добавить, ни несколько прокси, ни несколько IP не будут работать, если будет использовать всего один логин, а если логинов будет несколько, то вполне может прокатить и свой User-Agent привязанный к каждому логину, даже при работе с одного IP, ИМХО.
Логинов по-любому нужна пачка, когда мы с ProfitHunter’ом все это обсуждали, то такая тема звучала… НО! они реально нужны только для ГуглТрендс, для получения данных о количестве поисков в CSV-формате нужно обязательно залогниться, а данный скрипт именно в этом формате получает результаты. Для получения данных о количестве конкурентных страниц используется “обычный” парсинг гугла, и тут логин-пароль никак не работает. Что он есть, что его нет. Просто надо предусмотреть не только “лог-он” для обращения к гугл-трендс, но и “лог-офф” перед обращением за компетиторами. Ведь скрипт не получает все данные одним махом – он делает два разных запроса на два разных гугловых урла. Вернее три – еще и логин ведь. Ну а может делать 4 – не велика беда…
Впрочем, я же сказал что у меня лично сейчас используется не один логин (в данный момент 5, но сами понимаете – нарегистрировать еще аккаунтов не проблема, а в скрипте это мною предусмотрено)
А вот мысль о том, что можно еще добавить рандомизацию по юзер-агенту – эта мысль пожалуй очень даже не лишняя 😉 Надо будет попробовать. Жаль сейчас сразу не могу, ибо обрабатывается большой бъем и риск схлопотать бан (если он все-же в результате таких проб возникнет) мне сейчас совсем не к месту… Хоть и временное это дело бан от гугла, но как раз сейчас время особо ценно…
Хотя я по-прежнему считаю, что аккаунт на “вордтрекере” или на “вордзе” (или еще где-то типа нишебота) по-любому нужен если подходить к делу серьезно. А значит самый простой вариант – это вариант про “два захода” – сначала скриптом с отключенным получением конкурентов прогоняется основная база на чекинг серчей. А уже после этого отфильтрованная скармливается вордтрекеру, где проверяются именно компетиторы. Там их кстати за один заход можно сразу по двум поисковикам проверить, например по гуглу и яхе, или по гуглу и МСНу. При большом количестве слов (а вордтрекер позволяет в одном проекте до 25000 кейвордов) конечно проверять устанешь, но для этого буржуи уже постарались – есть “автоматизатор проверки компетиторов в вордтрекере” – запускаешь софтинку, заходишь в свой аккаунт, жмешь “проверять” и гуляешь или занимаешься своими делами. Через 2 часа у тебя в почтовом ящике лежит 25000 проверенных кейвордов. Кстати ни при каком подходе (если не использовать супер-скрипты на выделенных серваках) такое количество отпарсить на обычном хостере не реально за это время. Так что эксперименты конечно дело интересное, но надо же и работать – вот я пока для себя с рабочим вариантом определился…
Ну а помелочам, так сказать для текущих потребностей в сотню-другую проверяемых кеев, пока буду тестировать МаркетСамурай, о котором нам так любезно рассказал ПрофитХантер. За что ему отдельное спасибо 😉
Один момент учтите, если будет использовать юзер агент, предположим что нужно проверить 4 ключа (key1, key2, key3, key4) в 2 потока. Первый поток проверяет ключ key1, второй key2, когда первый поток перейдёт к ключу key3, то он ещё должен отправить refer с ключом key1, т.е. сделать вид что пользователь обработал один запрос и плавно перешёл к следующему, т.е. рефер не должен быть пустым. То же самое и для остальных потоков, имхо, в противном случае юзер агент может не сработать. Думаю не сильно ошибусь, если скажу, что гугль в первую очередь проверяет запросы с пустым рефером на бан.
По поводу вордтрекера, я слышал, что иногда он выдаёт данные отличающие от реальных на 1-2 порядка, кроме того, объёмы статистика гугля на несколько порядков больше, так что она будет понадёжнее, и бесплатно к тому же.
Если есть выделенный сервер, решение с нескольким IP от MegaS, мне нравится больше, т.к. оно в curl добавляется одной строчкой и его можно использоват как для гугля, так и для яху, так и для и алексы и т.п. Это если автоматизировать процесс до конца, те же 25000 ключей проверить за 2 часа вполне можно на ~12 IP-шниках. 1 запрос в 3,5 секунды (от 1 до 4 секунд задержка, 1 секунда на закачку) – это 1000 запросов за час, 2000 за 2, и при 12 IP должны спокойно обработаться. Если подождать подольше то 5 IP вполне достаточно.
А сделать ввод капчи, я предлагал для тех кто выделённого сервера не имеет, а сидит на денвере, например, или шаред хостинге.
Дополнение, описанный мной выше подход, подразумевает один юзер агент на всё время работы этого потока, иначе от рефера толку не будет.
Конечно. При такой нагрузке посетителей превышение одним умноженное на кол-во других может выбить сервери из колеи
Это вряд ли, то что я описал – всего 4 запроса в секунду. Например, пиковая нагрузка которую выдерживает MSN-поиск – это 1000 запросов в секунду на один кластер, а у них там не один десяток кластеров стоит.
Если имелся ввиду собственный сервер, то 4 запроса в секунду это тоже фигня, если правильно написаны скрипты.
Насчет рефера… Сейчас под рукой нет оригинального скрипта, только уже сильно переделанный и я не помню было ли это сразу (кажется все-же было) или я добавил… Каждый запрос к гуглю на логин и на парсинг передает ему рефер. Типа сначала зашел на гугль и только потом уже залогинился. Или сначала зашел на гугль и только потом уже послал поисковый запрос. Естественно, с получением, сохранением и возвращением “кукисов” – если их и нет на самом деле – это не беда, а вот если есть – это надо делать обязательно и curl это позволяет…
Насчет одного юзер-агента на поток – разумеется. И один логин-пароль на поток. Чтобы максимально приблизиться к среднестатистическому пользователю. Вы же, даже имея несколько разных гугловых аккаунтов, не перелогиниваетесь постоянно из одного в другой, в третий и так далее…
А вот насчет многих айпишников (вариант MegaS) – читайте мой комменатрий к нему. БЕЗ СПЕЦИАЛЬНОЙ ТЕСНОЙ БЕСЕДЫ С АДИМИНАМИ СЕРВЕРА ничего не выйдет, хоть ты обпокупайся этими айпишниками.
Только что проверил на одном их своих дедиков в “базовой” конфигурации которого есть 5 адресов. Когда с него обращаешься куда-либо наружу, все запросы идут от айпишника, привязанного к первой сетевухе (или к первому порту, если она многопортовая).
MegaS не ответил, так что я не могу знать как оно реально у него сделано. Но описание технической сложности было мною приведено для его варианта не просто так… Я, так уж вышло, системный администратор… Ну и еще про стоимость почитайте.
Так что “имея выделеный сервер” – я бы вам посоветовал купить прокси чекер (например Razor5 – я им доволен, сслок не даю чтобы за рекламу не заанил ПрофитХантер 😉 Это обойдется в тридцатку. После этого пишется многопоточный парсер, каждый поток которого уходит через проверенный чекером прокси – вот тогда скорость будет расти пропорционально накопленным в базе прокси-серверам. Только не стоит увлекаться новинками 5-го PHP типа мультикурла – реально он ждет ответа от самого медленного запроса и только потом продолжает работу. Надо именно много потоков, в кадом из которых по обычному curl используется. Тогда хоть в 20, хоть в 200 потоков можно работать, лишь бы канал был от выделенного сервера достаточно широким (а то есть и такие “дедики”, которые на 3 мегабитах подключены, но это не серьезно – я так дома через Стрим сижу)
В общем я вижу интерес к теме все-таки довольно большой. Наверное придется-таки скрипт дорабатывать и публиковать… Может быть…
Вот здесь посмотрите, как работать с несколькими IP на PHP:
http://masterhost.ru/support/doc/php/
ищете в тексте упоминание socket_bind, второй пример то что вам нужно. На PHP я это не применял, но на C мы с этим работали, для запросов к Yahoo XML всё прекрасно работало, даже вроде IP-шники были из одной подсети, но точно не помню, кстати говоря логин там был один на все IP, но это специфика Yahoo XML. Админ тут может и нужен, но только чтобы привязать к любой из имеющихся сетевых карт несколько IP, всё остальное делается из PHP.
Выделенного сервера у меня нет, а с проксями я работать не люблю, уж больно часто они в даун уходят, т.к. в текущий момент со скриптом автивно не работаю, то пока мне это не нужно, когда понадобится, я просто добавлю в него отслеживание ввода капчи и её непосредственный ввод, думаю временно это меня устроит.
Успеха в работе над скриптом.
еще вариант: купить у меня базу http://actualkeywords.com/ – там конкуренция для 180 000 000 кивордов уже собрана 😉
да, это процесс не быстрый, но мы сделали это и периодически обновляем. малыми средствами тут не обойтись кстати, стопудов!
Коллеги!
Мы несколько увлеклись процессом и забыли откуда ноги растут…
Напоминаю, что речь шла о БЕСПЛАТНОМ скрипте, который хотелось бы научить работать без бана гугла. Выделенные серваки, покупки айпишников пачками, база за 300 с лишним уев, платный прокси-чекер – ЭТО ВСЕ НА САМОМ ДЕЛЕ ВЕЩИ НУЖНЫЕ, но они не имеют отношения к теме этой дискуссии!
Давайте не будем забывать, что большинство читающих этот блог все-таки начинающие. Во всяком случае, я так для себя определяю направленность ProfitHunter’a – а уж он меня поправит если что. И тут рассказывается все ДЛЯ НИХ. И при этом в такой форме, чтобы ОНИ могли этими советами воспользоваться. Бесплатно зарегистрироваться на 30-day Challenge, получить бесплатную софтинку GTrends Made Easy (царство ей небесное) или Market Samurai. Найти относительно недорогого хостера и так далее и так далее… Чтобы им было с чего начинать.
А вот уже поднабравшись опыта (читай – “и понабивав шишки”) и заработав первые денежки они уже смогут ими распоряжаться. И покупать базы, и нанимать проф-программеров, и брать сервера с пачками айпишников и многое другое. Но на том этапе, на котором они сейчас находятся, им был предложен бесплатный скрипт, который работает, но имеет ряд ограничений (ну все же на халяву!) И речь только о том и шла: можно ли, реально ли, целесообразно ли предпринять некие действия для улучшения работы этого скрипта. Да так, чтобы он все-же остался бесплатным. Ну или относительно недорогим.
Давайте на этом и остановимся? Если кому-то есть что сказать ПО ТЕМЕ, а не просто проспамиться – велкам…
то al13: ты пишешь “Вот здесь посмотрите, как работать с несколькими IP на PHP: http://masterhost.ru/support/doc/php/
ищете в тексте упоминание socket_bind”
Читаем внимательно:
—первый пример (сам код я естественно тут писать не буду) —-
Использовать функцию socket_bind: При использовании PHP-интерпретатора как модуля Apache (по умолчанию на виртуальном хостинге именно так) работа с сокетами запрещена, поэтому следует использовать свой PHP-интерпретатор, собрать который можно по инструкции при конфигурировании обязательно указав ключ –enable-sockets.
———второй пример—————-
C помощью curl_setopt: В этом случае также потребуется собрать свой интерпретатор PHP, указав при конфигурировании ключ –with-curl=/usr/local.
————————————–
То есть, оба варианта подразумевают ПЕРЕКОМПИЛЛЯЦИЮ интерпретатора PHP, что вам ни один обычный хостер просто не позволит. Значит для этого вам нужен или виртуальный выделенный сервер (VDS or VPS) или настоящий выделенный сервер (дедик, dedicated) Что автоматически подразумевает ежемесячный платеж от 30$ для первого и до 100$-300$(и выше) второго…
Еще раз повторю – вариант СО МНОГИМИ КУПЛЕННЫМИ ЙАПИШНИКАМИ больше не рассматриваем, он в контексте обсуждаемой ситуации никак “не танцует”!
Кстати, вышеупомянтуая “инструкция” по которой можно собрать “свой собственный” интерпретатор PHP относится к акаунтам с полноценным shell-доступом. Что опять же, далеко не является обычной услугой хостера (читай – за это надо заплатить больше)
to Savos:
Вы не правильно поняли второй пример, если на хостинге работает ваш скрипт (в текущем виде), то это уже автоматически означает, что PHP был собран с ключом –with-curl=/usr/local, т.е. этот ключ означает что подключается именно curl, а не поддержка нескольких IP. Так что в данном случае требование не наличие shell, а именно наличие curl’а, если он есть то и второй пример будет работать. Между прочим сокеты тоже обычно включены, а то что они там рекомендуют PHP пересобрать, это по-видимому фишка masterhost, это не мой хостинг, просто первый попавшийся пример.
Между прочим, то что вы используете функцию iconv, она является ещё менее стандартной чем наличие curl, у меня например её на хостинге нет, и мне пришлось написать затычку, чтобы запустить скрипт.
PS. Я всегда ищу хостинг (шаред) с наличием шелла, у меня на хостинге он есть, но этот никак ещё не означает что я могу пересобрать PHP, потому что наличие шелл ещё никак не означает наличие C и команды make. А шелл в основном нужен для работа с БД при больших объемах, gzip, tar и т.п., ну по-крайней мере мне для этогою