Уйти от скриптов?
Постоянно читаю отклики разработчиков высоконагруженных приложений (коими парсеры и грабберы также являются) и просто стараюсь отслеживать что происходит в мире программирования и понемногу начинаю приходить к мысли, что при разработке самых крупных проектов надо отходить от скриптовых языков программирования и обращаться ко всяким там C++, C# и им подобным.
И по этому поводу хочу спросить, что думаю мои подписчики. Кто что пробовал? Какие тесты видели на эту тему? Какие шишки набили? Где многопоточность лучше показала себя? Что успели попробовать? Не молчите - выскажитесь! Поделитесь своим опытом, а другие поделятся с вами. И так все станут хоть на грамм умнее и эффективней!
Спасибо!
Anarki:
Ну C# явно врядли подойдет, ибо платформы нужны соответствующие Mono или .NET, а они тормозные и их еще устанавливать дополнительно нужно.
12 Февраль 2008, 7:35 ппadmin:
Мне тут просто один многоуважаемые “про” усердно рассказывал, что “все” высоконагруженные системы (к которым также относится и парсинг) надо писать на C#.
18 Февраль 2008, 9:58 дпAndrey:
Все действительно требовательное к ресурсам/скорости делаем на C(++).
+ работает на любом выделенном сервере/vps
21 Февраль 2008, 11:16 дп- как правило требуется установка доп. библиотек
admin:
А какой выигрыш по скорости мы получим, например, при переходе с PERL POE на C++ событийные машины и ее (сишную) реализацию многопоточности??? Это главный вопрос!
22 Февраль 2008, 9:49 дпAndrey:
Не сравнивали, т.к. не пишем на перле, да и на C многопоточность можно реализовывать по-разному (зачастую простого мултикурла хватает для решения задачи).
22 Февраль 2008, 10:07 дпПри работе с С узкое место перемещается на канал (если есть прокси то на них).
admin:
Но как я понимаю при работе на С++ также сложно проходит и процесс отладки. Потому что это уже компилиремый язык в отличии от общераспространенных интерпритируемых скриптов.
22 Февраль 2008, 10:49 дпИ как понять “узкое место перемещается на канал”? Предположим у меня гигабитный инет. Так вот я уверен, что при максимальной скорости и прочих благоприятных условиях узкое место переместится на сайт источник, потому что в инете (особенно в русском) не так много сайтов, которые могут отдавать динамические страницы (а чаще всего именно они и собираются) с большой скоростью.
Andrey:
Мы делаем серверные приложения, и грабим как правило не 1 источник, по жтому узкое место либо канал либо ресурсы. Если запустить даже на 10Mb/s C++ граббер на средниый сайт, то он проработает секунды 3 (на 100 потоков), потому упадет сервер БД.
24 Февраль 2008, 11:43 дпadmin:
А если заказ только на 1 источник? :))
27 Февраль 2008, 10:18 дпСервер бд упадет и при 20 потоках и на перловом / пхппешном граббере. Так что это не показатель. И как вы с подобными проблемами боретесь, кста?
Andrey:
Если заказ на 1 источник, то “узкое место”, как правило собвстенно сайт-донор и нет смысла писать на C++ (если только сайт не хоститься на ферме серверов).
29 Февраль 2008, 10:04 дпК сожалению, 100 % лекарства нет, есть некоторые хитрости как “разгрузить” донора, но это все равно не панацея (поискать зеркала, собирать страницы не с источника а кеша поисковиков или веб-архивов и т.д.) у них есть свои недостатки.
admin:
А на чем вы еще пишите? На пхп? Притом сайтов, которые имеют кластерное построение ОЧЕНЬ МАЛО
Кстати, кстати. Я пишу сейчас небольшую статью о методах разгрузки сайта-донора и мне было бы очень приятно выслушать ваше мнение по данному вопросу. Какие-то более хитрые уловки нежели просто зеркала и кеши? Я, например, очень часто использую селективные http запросы, лимитирую длину получаемого контента, использую граббинг PDA версий сайта, емейл рассылки и много прочего. Чем пользуетесь вы?
2 Март 2008, 10:48 дпMikhail:
Последнее, что я парсил это была микробаза региональных адресов. Парсил без сильной привязки к PHP, был настроен Ff3.1, так что бы он мог принимать по XHR urlы с другх доменов.
2 Февраль 2009, 6:27 ппСуть парсера проста до нельзя. Загружал индексную(ые) страницу(ы) в парсер. JS Скрипт (при поддержке Prototype.js) выделял все, что лежит в теге боди и заливал в “песочницу”, “пыточную камеру”, кому как нравится, для разделки боди по частям, затем с помошью $$ и регулярок вырезалось все что надо, как и данные, так и последующие ссылки для парсинга. РНР был всего лишь медиумом между СУБД и бразуером.
Плюсов несколько:
- мы максимально маскируемся под браузер (если удалить заголовок X-Requested-With, вродебы)
- простота написания правил парсинга, если источник хорошо структурирует данные тегами и атрибутами тегов
- 4 потока http 1.1
- можно отослать скрипт маме папе бабушке дедушке у которых нет сервера, но есть браузер, чтобы тоже помогали, но тут до ДДоСа не далеко
Сразу отмечу
Браузер не рендерит загруженный контент, контент выносится в -10000 -10000 и прячется display:none;
Парсер работает быстро — новый js движок ФФ хорошо делает свое дело.
admin:
У меня есть пару примеров парсеров, которые работают через ЯваСкрипт по описанным вами принципам. Они хороши, но все равно проигрывают пхп байт-код скриптам по скорости. Притом ПХП скриптов тоже можо запустить целую тучу и так добиться многопоточности (хотя это уже и будет называться многопроцесовностью).
26 Май 2009, 6:30 ппandy_sumy:
интересная постановка вопроса )) в принципе кто на чем умеет тот на том и пишет.
А как правильней это другое дело. Есть определенные закономерности и исходя из них определяется платформа реализации. Если Вам нужно Desktop и web приложение одновременно - пользуйте C# (но работать 100% стабильно будет только на Windows). Быстрая разработка, быстрая поддержка, кроссплатформенность (для грабберов) - Perl (для web приложений PHP). Минимальное использование ресурсов и максимальная производительность - С(С++). Есть еще Java, Python. Вообще я бы на ресурсы техники внимание не обращал - главное время разработчика и надежность работы - для этого конечно подходят языки высокого уровня.
“Где многопоточность лучше показала себя?” Ну давайте сравним Perl и С. Если Perl написан на С )) то где многопоточность будет лучше? )))
10 Декабрь 2009, 10:24 ппadmin:
Согласен, что перл написан на сях, но это еще не значит, что каждый сможет грамотно и качественно реализовать многопоточность именно на сях и получить лучший результат, чем на перл.
14 Декабрь 2009, 5:17 пп