Комментарии на запись: Уйти от скриптов? http://www.parse.com.ua/2008/01/25/ujti-ot-skriptov/ Профессиональный парсинг/граббинг/сбор информации Mon, 06 Feb 2012 01:13:39 +0000 http://wordpress.org/?v=2.2.3 От: admin http://www.parse.com.ua/2008/01/25/ujti-ot-skriptov/#comment-3220 admin Mon, 14 Dec 2009 14:17:10 +0000 http://www.parse.com.ua/2008/01/25/ujti-ot-skriptov/#comment-3220 Согласен, что перл написан на сях, но это еще не значит, что каждый сможет грамотно и качественно реализовать многопоточность именно на сях и получить лучший результат, чем на перл. Согласен, что перл написан на сях, но это еще не значит, что каждый сможет грамотно и качественно реализовать многопоточность именно на сях и получить лучший результат, чем на перл.

]]> От: andy_sumy http://www.parse.com.ua/2008/01/25/ujti-ot-skriptov/#comment-3216 andy_sumy Thu, 10 Dec 2009 19:24:10 +0000 http://www.parse.com.ua/2008/01/25/ujti-ot-skriptov/#comment-3216 интересная постановка вопроса )) в принципе кто на чем умеет тот на том и пишет. А как правильней это другое дело. Есть определенные закономерности и исходя из них определяется платформа реализации. Если Вам нужно Desktop и web приложение одновременно - пользуйте C# (но работать 100% стабильно будет только на Windows). Быстрая разработка, быстрая поддержка, кроссплатформенность (для грабберов) - Perl (для web приложений PHP). Минимальное использование ресурсов и максимальная производительность - С(С++). Есть еще Java, Python. Вообще я бы на ресурсы техники внимание не обращал - главное время разработчика и надежность работы - для этого конечно подходят языки высокого уровня. "Где многопоточность лучше показала себя?" Ну давайте сравним Perl и С. Если Perl написан на С )) то где многопоточность будет лучше? ))) интересная постановка вопроса )) в принципе кто на чем умеет тот на том и пишет.
А как правильней это другое дело. Есть определенные закономерности и исходя из них определяется платформа реализации. Если Вам нужно Desktop и web приложение одновременно - пользуйте C# (но работать 100% стабильно будет только на Windows). Быстрая разработка, быстрая поддержка, кроссплатформенность (для грабберов) - Perl (для web приложений PHP). Минимальное использование ресурсов и максимальная производительность - С(С++). Есть еще Java, Python. Вообще я бы на ресурсы техники внимание не обращал - главное время разработчика и надежность работы - для этого конечно подходят языки высокого уровня.

“Где многопоточность лучше показала себя?” Ну давайте сравним Perl и С. Если Perl написан на С )) то где многопоточность будет лучше? )))

]]> От: admin http://www.parse.com.ua/2008/01/25/ujti-ot-skriptov/#comment-3066 admin Tue, 26 May 2009 15:30:04 +0000 http://www.parse.com.ua/2008/01/25/ujti-ot-skriptov/#comment-3066 У меня есть пару примеров парсеров, которые работают через ЯваСкрипт по описанным вами принципам. Они хороши, но все равно проигрывают пхп байт-код скриптам по скорости. Притом ПХП скриптов тоже можо запустить целую тучу и так добиться многопоточности (хотя это уже и будет называться многопроцесовностью). У меня есть пару примеров парсеров, которые работают через ЯваСкрипт по описанным вами принципам. Они хороши, но все равно проигрывают пхп байт-код скриптам по скорости. Притом ПХП скриптов тоже можо запустить целую тучу и так добиться многопоточности (хотя это уже и будет называться многопроцесовностью).

]]> От: Mikhail http://www.parse.com.ua/2008/01/25/ujti-ot-skriptov/#comment-2971 Mikhail Mon, 02 Feb 2009 15:27:35 +0000 http://www.parse.com.ua/2008/01/25/ujti-ot-skriptov/#comment-2971 Последнее, что я парсил это была микробаза региональных адресов. Парсил без сильной привязки к PHP, был настроен Ff3.1, так что бы он мог принимать по XHR urlы с другх доменов. Суть парсера проста до нельзя. Загружал индексную(ые) страницу(ы) в парсер. JS Скрипт (при поддержке Prototype.js) выделял все, что лежит в теге боди и заливал в "песочницу", "пыточную камеру", кому как нравится, для разделки боди по частям, затем с помошью $$ и регулярок вырезалось все что надо, как и данные, так и последующие ссылки для парсинга. РНР был всего лишь медиумом между СУБД и бразуером. Плюсов несколько: - мы максимально маскируемся под браузер (если удалить заголовок X-Requested-With, вродебы) - простота написания правил парсинга, если источник хорошо структурирует данные тегами и атрибутами тегов - 4 потока http 1.1 - можно отослать скрипт маме папе бабушке дедушке у которых нет сервера, но есть браузер, чтобы тоже помогали, но тут до ДДоСа не далеко :-) Сразу отмечу Браузер не рендерит загруженный контент, контент выносится в -10000 -10000 и прячется display:none; Парсер работает быстро -- новый js движок ФФ хорошо делает свое дело. Последнее, что я парсил это была микробаза региональных адресов. Парсил без сильной привязки к PHP, был настроен Ff3.1, так что бы он мог принимать по XHR urlы с другх доменов.
Суть парсера проста до нельзя. Загружал индексную(ые) страницу(ы) в парсер. JS Скрипт (при поддержке Prototype.js) выделял все, что лежит в теге боди и заливал в “песочницу”, “пыточную камеру”, кому как нравится, для разделки боди по частям, затем с помошью $$ и регулярок вырезалось все что надо, как и данные, так и последующие ссылки для парсинга. РНР был всего лишь медиумом между СУБД и бразуером.
Плюсов несколько:
- мы максимально маскируемся под браузер (если удалить заголовок X-Requested-With, вродебы)
- простота написания правил парсинга, если источник хорошо структурирует данные тегами и атрибутами тегов
- 4 потока http 1.1
- можно отослать скрипт маме папе бабушке дедушке у которых нет сервера, но есть браузер, чтобы тоже помогали, но тут до ДДоСа не далеко :-)
Сразу отмечу
Браузер не рендерит загруженный контент, контент выносится в -10000 -10000 и прячется display:none;
Парсер работает быстро — новый js движок ФФ хорошо делает свое дело.

]]> От: admin http://www.parse.com.ua/2008/01/25/ujti-ot-skriptov/#comment-156 admin Sun, 02 Mar 2008 07:48:08 +0000 http://www.parse.com.ua/2008/01/25/ujti-ot-skriptov/#comment-156 <blockquote>Если заказ на 1 источник, то “узкое место”, как правило собвстенно сайт-донор и нет смысла писать на C++ (если только сайт не хоститься на ферме серверов).</blockquote> А на чем вы еще пишите? На пхп? Притом сайтов, которые имеют кластерное построение ОЧЕНЬ МАЛО :) <blockquote>К сожалению, 100 % лекарства нет, есть некоторые хитрости как “разгрузить” донора, но это все равно не панацея (поискать зеркала, собирать страницы не с источника а кеша поисковиков или веб-архивов и т.д.) у них есть свои недостатки.</blockquote> Кстати, кстати. Я пишу сейчас небольшую статью о методах разгрузки сайта-донора и мне было бы очень приятно выслушать ваше мнение по данному вопросу. Какие-то более хитрые уловки нежели просто зеркала и кеши? Я, например, очень часто использую селективные http запросы, лимитирую длину получаемого контента, использую граббинг PDA версий сайта, емейл рассылки и много прочего. Чем пользуетесь вы?

Если заказ на 1 источник, то “узкое место”, как правило собвстенно сайт-донор и нет смысла писать на C++ (если только сайт не хоститься на ферме серверов).

А на чем вы еще пишите? На пхп? Притом сайтов, которые имеют кластерное построение ОЧЕНЬ МАЛО :)

К сожалению, 100 % лекарства нет, есть некоторые хитрости как “разгрузить” донора, но это все равно не панацея (поискать зеркала, собирать страницы не с источника а кеша поисковиков или веб-архивов и т.д.) у них есть свои недостатки.

Кстати, кстати. Я пишу сейчас небольшую статью о методах разгрузки сайта-донора и мне было бы очень приятно выслушать ваше мнение по данному вопросу. Какие-то более хитрые уловки нежели просто зеркала и кеши? Я, например, очень часто использую селективные http запросы, лимитирую длину получаемого контента, использую граббинг PDA версий сайта, емейл рассылки и много прочего. Чем пользуетесь вы?

]]> От: Andrey http://www.parse.com.ua/2008/01/25/ujti-ot-skriptov/#comment-155 Andrey Fri, 29 Feb 2008 07:04:12 +0000 http://www.parse.com.ua/2008/01/25/ujti-ot-skriptov/#comment-155 Если заказ на 1 источник, то "узкое место", как правило собвстенно сайт-донор и нет смысла писать на C++ (если только сайт не хоститься на ферме серверов). К сожалению, 100 % лекарства нет, есть некоторые хитрости как "разгрузить" донора, но это все равно не панацея (поискать зеркала, собирать страницы не с источника а кеша поисковиков или веб-архивов и т.д.) у них есть свои недостатки. Если заказ на 1 источник, то “узкое место”, как правило собвстенно сайт-донор и нет смысла писать на C++ (если только сайт не хоститься на ферме серверов).
К сожалению, 100 % лекарства нет, есть некоторые хитрости как “разгрузить” донора, но это все равно не панацея (поискать зеркала, собирать страницы не с источника а кеша поисковиков или веб-архивов и т.д.) у них есть свои недостатки.

]]> От: admin http://www.parse.com.ua/2008/01/25/ujti-ot-skriptov/#comment-147 admin Wed, 27 Feb 2008 07:18:00 +0000 http://www.parse.com.ua/2008/01/25/ujti-ot-skriptov/#comment-147 А если заказ только на 1 источник? :)) Сервер бд упадет и при 20 потоках и на перловом / пхппешном граббере. Так что это не показатель. И как вы с подобными проблемами боретесь, кста? А если заказ только на 1 источник? :))
Сервер бд упадет и при 20 потоках и на перловом / пхппешном граббере. Так что это не показатель. И как вы с подобными проблемами боретесь, кста?

]]> От: Andrey http://www.parse.com.ua/2008/01/25/ujti-ot-skriptov/#comment-145 Andrey Sun, 24 Feb 2008 08:43:33 +0000 http://www.parse.com.ua/2008/01/25/ujti-ot-skriptov/#comment-145 Мы делаем серверные приложения, и грабим как правило не 1 источник, по жтому узкое место либо канал либо ресурсы. Если запустить даже на 10Mb/s C++ граббер на средниый сайт, то он проработает секунды 3 (на 100 потоков), потому упадет сервер БД. Мы делаем серверные приложения, и грабим как правило не 1 источник, по жтому узкое место либо канал либо ресурсы. Если запустить даже на 10Mb/s C++ граббер на средниый сайт, то он проработает секунды 3 (на 100 потоков), потому упадет сервер БД.

]]> От: admin http://www.parse.com.ua/2008/01/25/ujti-ot-skriptov/#comment-142 admin Fri, 22 Feb 2008 07:49:55 +0000 http://www.parse.com.ua/2008/01/25/ujti-ot-skriptov/#comment-142 Но как я понимаю при работе на С++ также сложно проходит и процесс отладки. Потому что это уже компилиремый язык в отличии от общераспространенных интерпритируемых скриптов. И как понять "узкое место перемещается на канал"? Предположим у меня гигабитный инет. Так вот я уверен, что при максимальной скорости и прочих благоприятных условиях узкое место переместится на сайт источник, потому что в инете (особенно в русском) не так много сайтов, которые могут отдавать динамические страницы (а чаще всего именно они и собираются) с большой скоростью. Но как я понимаю при работе на С++ также сложно проходит и процесс отладки. Потому что это уже компилиремый язык в отличии от общераспространенных интерпритируемых скриптов.
И как понять “узкое место перемещается на канал”? Предположим у меня гигабитный инет. Так вот я уверен, что при максимальной скорости и прочих благоприятных условиях узкое место переместится на сайт источник, потому что в инете (особенно в русском) не так много сайтов, которые могут отдавать динамические страницы (а чаще всего именно они и собираются) с большой скоростью.

]]> От: Andrey http://www.parse.com.ua/2008/01/25/ujti-ot-skriptov/#comment-141 Andrey Fri, 22 Feb 2008 07:07:31 +0000 http://www.parse.com.ua/2008/01/25/ujti-ot-skriptov/#comment-141 Не сравнивали, т.к. не пишем на перле, да и на C многопоточность можно реализовывать по-разному (зачастую простого мултикурла хватает для решения задачи). При работе с С узкое место перемещается на канал (если есть прокси то на них). Не сравнивали, т.к. не пишем на перле, да и на C многопоточность можно реализовывать по-разному (зачастую простого мултикурла хватает для решения задачи).
При работе с С узкое место перемещается на канал (если есть прокси то на них).

]]>