Уйти от скриптов?
Постоянно читаю отклики разработчиков высоконагруженных приложений (коими парсеры и грабберы также являются) и просто стараюсь отслеживать что происходит в мире программирования и понемногу начинаю приходить к мысли, что при разработке самых крупных проектов надо отходить от скриптовых языков программирования и обращаться ко всяким там 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 дп