Уйти от скриптов?

Постоянно читаю отклики разработчиков высоконагруженных приложений (коими парсеры и грабберы также являются) и просто стараюсь отслеживать что происходит в мире программирования и понемногу начинаю приходить к мысли, что при разработке самых крупных проектов надо отходить от скриптовых языков программирования и обращаться ко всяким там C++, C# и им подобным.

И по этому поводу хочу спросить, что думаю мои подписчики. Кто что пробовал? Какие тесты видели на эту тему? Какие шишки набили? Где многопоточность лучше показала себя? Что успели попробовать? Не молчите - выскажитесь! Поделитесь своим опытом, а другие поделятся с вами. И так все станут хоть на грамм умнее и эффективней!

Спасибо!

10 комментариев

  1. Anarki:

    Ну C# явно врядли подойдет, ибо платформы нужны соответствующие Mono или .NET, а они тормозные и их еще устанавливать дополнительно нужно.

  2. admin:

    Мне тут просто один многоуважаемые “про” усердно рассказывал, что “все” высоконагруженные системы (к которым также относится и парсинг) надо писать на C#.

  3. Andrey:

    Все действительно требовательное к ресурсам/скорости делаем на C(++).

    + работает на любом выделенном сервере/vps
    - как правило требуется установка доп. библиотек

  4. admin:

    А какой выигрыш по скорости мы получим, например, при переходе с PERL POE на C++ событийные машины и ее (сишную) реализацию многопоточности??? Это главный вопрос!

  5. Andrey:

    Не сравнивали, т.к. не пишем на перле, да и на C многопоточность можно реализовывать по-разному (зачастую простого мултикурла хватает для решения задачи).
    При работе с С узкое место перемещается на канал (если есть прокси то на них).

  6. admin:

    Но как я понимаю при работе на С++ также сложно проходит и процесс отладки. Потому что это уже компилиремый язык в отличии от общераспространенных интерпритируемых скриптов.
    И как понять “узкое место перемещается на канал”? Предположим у меня гигабитный инет. Так вот я уверен, что при максимальной скорости и прочих благоприятных условиях узкое место переместится на сайт источник, потому что в инете (особенно в русском) не так много сайтов, которые могут отдавать динамические страницы (а чаще всего именно они и собираются) с большой скоростью.

  7. Andrey:

    Мы делаем серверные приложения, и грабим как правило не 1 источник, по жтому узкое место либо канал либо ресурсы. Если запустить даже на 10Mb/s C++ граббер на средниый сайт, то он проработает секунды 3 (на 100 потоков), потому упадет сервер БД.

  8. admin:

    А если заказ только на 1 источник? :))
    Сервер бд упадет и при 20 потоках и на перловом / пхппешном граббере. Так что это не показатель. И как вы с подобными проблемами боретесь, кста?

  9. Andrey:

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

  10. admin:

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

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

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

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

Оставить комментарий