Реальны ли высокопроизводительные Web-приложения на C++?

    В данный момент стоит вопрос о разработке высокопроизводительного веб-приложения, которое могло бы выдерживать миллионы хитов в день.
    Целевая нагрузка от 1000 хитов в секунду и выше (вплоть до заполнения гигабитного канала).

    Имел ли кто-либо из читателей опыт разработки веб-приложений на С++? Предлагаю обсудить сложности и ограничения.
    Подразумевается что приложение не будет иметь утечек памяти(и соответственно проблем со стабильностью), и 2-3-х кратное увеличение цены разработки по сравнению с PHP приемлимо.

    Какие варианты вижу я:


    Для всех вариантов: сервер обрабатывает только динамический контент, вся статика на отдельных серверах / CDN.

    1) fastcgi модуль Apache/nginx, хранит всю нужную информацию в памяти, изредка сбрасывая критичные данные в MySQL (ну и сложные но редкие запросы можно в MySQL)
    2) сам себе апач: приложение само обрабатывает HTTP запросы, используя например имеющуюся реализацию в библиотеке Poco
    3) Забить на C++ и сделать на PHP+APC с кешированием данных внутри APC.
    4) Забить на C++ и сделать на PHP+APC с кешированием данных внутри memcached, сразу расчитывая ставить кучу серверов.

    Какие мнения?

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 264

      +21
      При таком кол-ве запросов уже не язык спасает, а кол-во серверов, кеширование и т.п.
        0
        Это понятно, но все же напарсить 50-100 Мб HTML-я в секунду на интерпретируемых языках нереально(ИМХО), а на C++ — вполне, ИМХО.
          –7
          есть причины по которым не подходит C#?
            +1
            Не вижу преимуществ C# перед Java, оба даже с JIT-компиляцией медленнее(хоть и не сильно) правильного C++ кода.
            А вот расход памяти меня всегда пугал. Также, у C# ограничения на хостинг (mono не в счет :-) ).
            Есть ли у кого примеры Java-приложений, которые выжмут 1000 хитов на одном боксе?

            Цена разработки стоит на втором месте, главное это скорость.

            Если переходить на несколько серверов, сразу падает скорость/сервер (из-за затрат на синхронизацию и проч.) насколько я понимаю, поэтому и хочется обойтись одним толстым сервером.
              +6
              Есть пример Java приложения выжимющего до 30к соединений на одном боксе. Там правда не Http а Sip но оно структурно похоже.
              Есть аналог того же но на шарпе. И даже на с++ есть. И у всех скорость одинаковая.
              Так что не язык решает а архитектура.
                0
                А можно более конкретно озвучить название Java SIP, которое в состоянии обрабатывать 30k инвайтов в секунду?
                Вы же это имели ввиду? Хотя бы как примитивнейший Sip Location?
                Очень хотелось бы посмотреть на архитектуру в образовательных целях.
                  0
                  Название к сожалению озвучить нельзя, ибо NDA. Копайте в сторону NIO (там уже разницы нету, либо свой велосипед либо Apache MINA).
                  Точто делал я работало именно на совем велосипеде поверх NIO и основной затык был в парсинге текста а не в чем либо другом. И кстати обрабатывало именно инвайты :)
                  Архитектура — два потока. «Acceptor» и «Proxifier» (ну вот так они назывались в реализации). Первый соответственно принимал на себя подключения и давал на растерзание второму.
                    0
                    Я просто тоже связан с этим вопросом.
                    И никоим образом не могу поверить в 30к/с полноценно обработанных транзакций Sip Location на Java. :(
                      0
                      Я вот тоже одно время был связан с этим вопросом. В результате все написалось на java. Конкретно по ней же. Если вопросы синхронизации свести к минимуму и рассматривать каждый пакет независимо (ака сделать эдакий state machine с минимум синхронизаций) то все будет работать. У нас основной оверхед был на синхронизации 10+к объектов. Памяти правда жралось тоже много, но это были терпимые издержки. Опятьпосмотрите информацию по Mina. Товарищи рассказывают про 40-50к запросов на SMS-шлюз, во что я тоже охотно верю.
                        0
                        Простите конечно за назойливость, но я не вижу там указанных Вами цифр:
                        mina.apache.org/performance-test-reports.html

                        Там написано про 25к, но при этом они сравнивают ЦЕЛЫЙ апач и некий "… the AsyncWeb lightweight HTTP server example ....". Наверняка прям в памяти заготовлен ответ, и запрос они могут вообще не разглядывать (хотя беглый взгляд показал, что они их хоть парсят).
                        Сравнение — чушь несусветная. При этом апач 2.0, а тогда и люди были другие, и сервера тупее.
                        Более современные версии апача и таких результатов не покажут (только предположение).

                        Жаль что пруфлинков более адекватных нет. Реально очень интересен мне этот вопрос.
                          0
                          Уважаемый, я не пытаюсь убедить вас в том что Mina — панацея. Кстати те самые цифры были в презентациях и keynotes на их же сайте (вполне может что и не на офф. сайте. Помню что с выступлений 2006-2007гг. Как вариант на каких либо университетских ресурсах. ). Там один из разработчиков подробно описывал как они делали SMS-gate какая была архитектура и где что и как :)
                +11
                Если говорить о C#, то лично моё имхо состоит в следующем. C# ограничивает вас в выборе платформы, а это, судя по условиям задачи, один из критичных параметров. От обычного .NET приложения не стоит ждать производительности и, что очень важно, бережного отношения к памяти. IIS, несмотря на рекламу, все-таки не самый скоростной и легковесный сервер, не самый защищенный и т.д. и т.п. А еще это средство жутко будет сковывать вас в выборе технологий и компонентов, которые могли бы облегчить вам жизнь.

                В отличие от вышеназванного средства, java проще заставить работать быстро и в практически любой среде. Никаких сопоставительных тестов не проводил, но верю, что это работает быстрее php/python/ruby/etc. Т.е. с java вы получите адаптируемость к нагрузкам, относительную простоту разработки и довольно высокую скорость выполнения кода. Для многих частей системы я бы выбрал эту среду.

                Самое главное — понять, что ни плюсы, ни java не помогут вам, если ваша система не будет хорошо спроектированной. Архитектура системы будет иметь больший вес, чем инструментальное средство.

                По всей видимости, вам придется делать множество прототипов, долго и кропотливо описывать и обдумывать каждую деталь и только после этого выбирать. Если, например, поиск быстрее заработает на бейсике, то не все ли равно, нравится ли это приверженцам с-+.

                Кстати, чуть не забыл, на java написан LinkedIn и делаются SIP решения.
                  +4
                  «IIS, несмотря на рекламу, все-таки не самый скоростной и легковесный сервер, не самый защищенный и т.д. и т.п.»

                  Хотел бы заметить, что желаемое за действительное выдавать тоже не стоит.

                  Любой веб-сервер, несмотря на рекламу, все-таки не самый скоростной и легковесный, не самый защищенный и т.д. и т.п.

                  То, что действительно является аргументом — так это то, что .NET ограничивает в выборе платформы. Остальные доводы ничем не подтверждены. Особенно про простоту разработки.
                    +8
                    Как это — любой?
                    Один какой-то в любом случае будет самым скоростным и легковесным)))
                    И один будет самым защищённым, возможно даже это будет один и тот же.

                    Хотя согласен, что ограниченность в выборе платформы более веский аргумент.
                      +1
                      >Как это — любой?
                      Он радиус кривизны рук имел ввиду.
                    –1
                    Почему C# ограничивает в выборе платформы? Чем плох mono и fastcgi?
                      0
                      Тем что fastcgi уже довольно сильно транжирит ресурсы. Выбора в любом случае гораздо меньше, чем с Java.
                    0
                    набежали тролли и заминусовали :)
                    однако, сборки .net (в том числе и C#) вы можете компилировать в нативный код платформы x86 или ia64 и никакая JIT-компиляция задействована не будет, не уверен, может ли java компилировать код в нативный

                    попробую предположить, что такой вариант будет не сильно медленнее C++ кода
                    • UFO just landed and posted this here
                        +1
                        И декодер MPEG2 использует векторизацию в SSE-команды?
                        © Не верю :-)
                        • UFO just landed and posted this here
                            +2
                            К сожалению использовать SSE-инструкции и векторизацию — это не одно и то же. То, что они используют SSE автоматически не значит, что выполняется векторизация (или даже что делаются попытки её выполнить). SSE можно использовать и для скалярных вычислений. Для Java это имеет преимущество перед FPU потому, что спецификация Java накладывает довольно сильные ограничения на вещественную арифметику, из-за чего при наличии одновременно float- и double-операций требуется либо переключать точность на FPU, либо вставлять дополнительные чтения/записи в память.

                            На самом деле и не все С/С++ компиляторы могут хорошо выполнять векторизацию. Обычно славится этим Intel (ну ещё бы, не удивительно!).

                            Вообще, Java несколько затрудняет выполнение векторизации. Взять хотя бы выполнение проверок на выход за границы массива. Для успешного выполнения векторизации, помимо других условий, требуется сначала избавиться от этих проверок, что в общем случае делается с помощью версионирования циклов (в HotSpot используется схема с так называемой деоптимизацией). А версионирование, к сожалению, в HotSpot пока не сильно мощное.
                              +1
                              кстати об Интелловцах: в их лаборатории при НГУ есть как раз проект по реализации векторизации в OpenJDK (http://www.i-lab.nsu.ru/index.php?newsid=70).
                              • UFO just landed and posted this here
                                  +1
                                  Смысла использовать float на FPU вообще нету. Но всё зависит от архитектуры, на которой работает JVM. При использовании float например на x86 можно лучше сделать векторизацию (выполнить больше операций за раз), а например на ARM разместить на регистрах в два раза больше переменных.
                            0
                            > Большинство из них писаны студентами за еду.

                            *Все* программы, с которыми я сталкивался, на Яве, жрали память, место на диске и тормозили (включая к примеру Zend Studio  — ее что тоже студенты писали). Может все-таки дело в самом языке?

                            А приеденный пример с декодером —может он на си написан и просто обернут в Java-класс?

                            И человек в комментах пишет, Hello World ест 17 Мб памяти (когда я изучал по учебе java, не по своей воле(, я тоже на этио обратил внимание.

                            Да и как многоэтажное дерево классов может вообще быть эффективным, а?

                            Что-то как-то то, с чем я сталкивался, противоречит тому, что вы пишете.
                            • UFO just landed and posted this here
                            0
                            > может ли java компилировать код в нативный
                            да, gcj, но его вообще нечасто используют, а уж для веба — почти никогда.
                              0
                              существуют и коммерческие компиляторы, например, Еxcelsior JET
                                0
                                да, точно, про него я что-то забыл.
                              –1
                              сборка мусора все усилия сведет на нет. в то время как на C (и в гамаке на C++) можно просто программировать на пулах и точно так же не заботиться об освобождении памяти.
                                0
                                Думаю, не стоит начинать тут холивар Java vs .NET :)
                                Обе технологии примерно одинаковы по своим преимуществам, но различаются в деталях — тут уже кому что больше нравится или каквы изначальные требования. Java более кроссплатформенна, однако у MS так или иначе — интеграция со своими другими технологиями (от Dynamics до Office Desktop) и средствами разработки.
                                Ну и много всего другого, не хочу здесь начинать это обсуждение.
                                0
                                1000 хитов в секунду на java — вполне реальность, сам лично делал на 1 ядре (на целероне).
                                А если это будет HelloWorld и keep-alive соединения то и 10000 в секунду выдержит.
                                  0
                                  Ага. Главное — быть поосторожнее с памятью, а то java любит задумываться, когда gc просыпается :)
                                    +1
                                    В принципе, производительность была постоянной.
                                    Если скачки и были то в интервалах сильно меньше 1 секунды, потому что в любую из секунд сервер обрабатывал необходимые 1000 реквестов :)
                                    А вообще самое медленное с чем я столкнулся — это выделение памяти под массивы (в частности массивы байтов), это прям съедало основное время, поэтому я сам распарсивал реквесты, все данные перегонял по запуленным массивам байтов, ну и конечно же nio, так как 1000 thread'ов тоже просто убивают jvm :)
                                    Если интересно посмотреть мои поделки детства то оно вот тут sourceforge.net/projects/ixstrim/
                                      0
                                      Думаю, что тут просто многие под Java понимают использование какого-либо APP-сервера.

                                      То, что C++, Java и C# при использовании схожей архитектуры будут показывать сравнимую производительность, по-моему очевидно.
                                        0
                                        Про APP-сервера возможно Вы правы :)
                                        Про сравнимую производительность при схожей архитектуры тоже правы :)

                                        Перед тем как начать использовать java (это было в 1999 году), первое что я сделал — это проверил как отличается производительность Java vs Си на трех задачах:
                                        1) qsort (разница была 5% в пользу Си)
                                        2) передача данных по сети просто пинг сервер и клиент, разницы не было
                                        3) операции с жестким диском (тестировались потоковое чтение и seek'и) разницы не было

                                        На Си тесты писали матерые перцы, так что все было по честному :)
                                • UFO just landed and posted this here
                                +6
                                У вас несколько вариантов
                                1.Перенимайте опыт у google, многие процессы у них на python, и как уже писали ниже, некоторые можно точить на С++.
                                2.Используйте C#, он даст скорость в разработке, я думаю раза в два.
                                3.С++
                                4.Свои велосипеды.
                                  0
                                  1. Насколько я знаю в Google ничего держащего большую нагрузку не использует Python. Вот «обвязка» (системы мониторинга, отчёты, оффлайновая обработка данных) — это да.
                                  2. Я очень сомневаюсь что C# даст сильно бо́льшую скорость чем Java. Он даст экономию на программистах, но тут вроде это не главное.
                                    0
                                    >Я очень сомневаюсь что C# даст сильно бо́льшую скорость чем Java.
                                    Не в этом суть, это один из вариантов — использование высокоуровневого языка.

                                    На самом деле думаю автор не посмотрит в сторону java и c#.
                                    0
                                    Движок гугла был сделан на C++ и поставлен на линукс, дальнейшая судьба мегакластера неизвестна :)
                                  • UFO just landed and posted this here
                                      +6
                                      нам почти заказали сайт на Ассемблере. еле удалось убедить манагеров, что никто из разработчиков не знает asm.

                                      эх, весёлое было времечко… (;
                                        +29
                                        То что скомпиленный рукописный асм-код будет быстрее скомпиленного современным компилятором рукописного кода на Си (++, etc) — распространенное заблуждение. При кодировании на асме сложного приложения руками надо учесть СТОЛЬКО факторов и столько всего в голове держать, столько всяких вещей просчитывать, что человеку это если и под силу, то ооооооочень медленно и с кучей (трудноуловимых) ошибок.
                                          0
                                          Это миф. Во-первых, чтобы Си (и тем более Си++)-программа была эффективной, тоже надо держать в голове кучу факторов, надо фактически писать как на асме, достаточно один раз использовать например STL — и сразу же вес программы подскочит, а производительность нет.

                                          И почему интересно компилятор генерирует более эффективный код, чем человек? Что железка умнее?
                                            +1
                                            > Во-первых, чтобы Си (и тем более Си++)-программа была эффективной, тоже надо держать в голове кучу факторов,

                                            Вот только при написании на Си не надо держать в голове тех вещей, которые надо деражть когда пишешь на голом асме. Многое берёт на себя компилятор.

                                            > достаточно один раз использовать например STL — и сразу же вес программы подскочит, а производительность нет.

                                            С удовольствием посмотрю, как вы воспользуетесь STL в C :). А если серьёзно, то STL-ем тоже надо уметь пользоваться.

                                            Никто не говорит, что код на Си всегда более эффективен, естественно надо писать с умом. Но, соглситесь, гораздо проще возложить много рутинной и очень сложной работы по раскидыванию переменных по регистрам (переменных много, а регистров мало), по описанию всяких вызовов функций, по input/output (в том числе файловом) и т.п. на компилятор и озадачится написанием эффективного кода на более высоком уровне абстракции (всё таки Си это язык более выского уровня чем асм, хотя и не такого как, например, питон).

                                            Попробуйте написать какое-нибудь более-менее нетривиальное приложение на Си (например, простой лексический анализатор) и на асме — поймёте о чем я говорю.
                                              +1
                                              Компилятор может генерировать более эффективный код именно потому, что он железка, и ему всё равно, какого размера получится код функцийй — 200 инструкций или 2000 инструкций.

                                              Конечно железяка не сравнится с человеком, но чтобы написать код более эффективно, чем это делает компилятор, требуется потратить много усилий. Человек может позволить себе это для нескольких мест в программе, но на то чтобы сделать это со всей программой просто не хватит времени и сил, а код в результате получится неподдерживаемым.

                                              Примеры банальны: Как часто вы на ассемблере делаете:
                                              1) Открытую подстановку (инлайн), вместе с протяжкой констант, удалением неиспользуемого кода и вычислением константных выражений и после этого ещё и новым перераспределением регистров? Как обстоят дела с поддержкой такого кода?

                                              2) Часто ли вы делаете раскрутку циклов более сложных, чем пара инструкций (например инструкций 15)?
                                                0
                                                Ну, то что вы упомянули не всякий компилятор сделает. Хотя человеку думаю ручной раскруткой циклов не очень-то интересно заниматься будет.
                                                  0
                                                  1-е делают все современные :-)
                                                  2-е хорошо в основном Intel C++ (впрочем он много чего делает хорошо)
                                                    0
                                                    Ну вот осталось только придумать сопособ заставить всех разработчиков пользоваться хорошими компиляторами.
                                            +1
                                            забавно будет увидеть вэбфрамеворк на ассемеблере))
                                            0
                                            highscalability.com/
                                            Там есть примеры и LAMP-систем. Например, Digg…
                                              +2
                                              еще могу посоветовать: www.insight-it.ru
                                              Есть цикл статей про архитектуру высоконагруженных сервисов: flickr, google, youtube, ЖЖ, wikimedia и т.д.
                                                0
                                                Спасибо, конечно, за рекламу :)
                                                Правда источником информации для большинства этих постов послужил как раз упомянутый чуть выше блог Тодда Хоффа)
                                              0
                                              Веб приложение же вроде генерит HTML, а не парсит?
                                              А если парсить надо, то я делал самописный HTML парсер по подобию SAX, дак он на одном ядре 3000Мгц 70Мб/сек парсил, и оптимизировать еще было куда.
                                              Это я про java говорю.
                                                +3
                                                Стоимость работы cpp программистов дороже стоимости дополнительного железа.

                                                Скорость разработки на cpp намного ниже, чем у простых интерпретируемых языков.

                                                Да и вообще, критичные к производительности модули и так делаются на c.

                                                Если вдруг вам самим потребовалось что-то сделать быстрым, то проще изучить инструменты типа swig, которые позволяют преобразовать код на питоне, например, в код на c и собрать бинарный модуль под конкретную небольшую задачу, оставив управляющий код тому же питону.

                                                0
                                                1. Сервер — 1GHz P3 2G 18G scsi
                                                Держал до 40 миллионов хитов в сутки. Тормозить начал, когда трафик приблизился к 60 миллионам в сутки.
                                                Выполняемая функция — хостинг баннерообменных сеток на своем движке.
                                                2. Статистика Liveinternet.ru:
                                                roem.ru/2009/01/26/addednews9350/?c#message31540
                                                4 сервера во фронтенде. Суточный трафик — порядка 2 миллиардов (с хвостиком) хитов — www.liveinternet.ru/stat/ru/
                                                Получаем в среднем от 500 миллионов хитов на сервер в сутки.
                                                При таком количестве запросов спасает не только язык, но и руки того, кто делает задачу.
                                                +4
                                                Я думаю что такие масштабы надо как-то и проектировать и писать по другому.
                                                Я где-то читал что вот в Yaндексе сначала пишут тестовый вариант на Python. Это быстро и удобно.
                                                Потом это все переводится на C (С++). Добиваются максимальной производительности.
                                                  +2
                                                  Безусловно, писаться будет изначально по другому. 10 SQL запросов на страницу не будет.
                                                  В идеале — 1 SQL запрос на 10 хитов, остальное в памяти :-)

                                                  насчет Python — уверен, прототип можно писать на любом из современных языков веб разработки (PHP/Perl/Ruby — кому что удобнее, мне PHP например).
                                                    +3
                                                    Идеалогия Python осень сильно отличается от PHP, и очень подходит именно для написания веб-приложения. Если вспомнить, что оптимизировать нужно в своё время, то Python, с его возможностью написания модулей на C — просто конфетка.
                                                      –3
                                                      писать extention для PHP религия не позволяет?
                                                        +8
                                                        Лично я не пробовал писать модули для Python на Си, но зато пробовал extension для PHP — камасутра ещё та.
                                                        Zend Engine 2 вышел уже бог знает сколько лет назад (вместе с PHP 5), а по нему до сих пор нет толковой официальной документации!
                                                        Пришлось лезть в сорцы расширений из PECL'а и расшифровывать их.
                                                        При всей моей любви к PHP, в этом плане он меня сильно разочаровал :(

                                                        Кстати, возможно документация/туториалы есть, но я их не нашел — тогда буду благодарен за ссылку. Желательно с нормальными примерами использования объектов, а то я находил сплошные костыли типа ZEND_NAMED_FE.
                                                          +1
                                                          Ммм… Что является аналогом Cython для PHP, не напомните?
                                                        0
                                                        на прошлой работе делали один очень похожий архитектурно проект
                                                        написали на Си, sql нет вообще — все в бинарных самописных бд, оператиыные данные — в памяти
                                                        http обрабатывается lighttpd+fastcgi
                                                        ожидаемая нагрузка — по 1 млн динамических хитов на ноду (всего 3 ноды)
                                                        писал один человек в течении примерно 3 месяцев
                                                          0
                                                          > писал один человек в течении примерно 3 месяцев

                                                          сколько времени ушло на тестирование? вот что важно на самом деле.
                                                            0
                                                            в человеко-часах сейчас не возьмусь оценить, примерно так — 4-5 человек, по 2-3 часа в течении 2 месяцев
                                                            но нельзя назвать это нагрузочным тестированием, т.к. в этих рамках происходило и тестирование хтмл-интерфейсов, юзабилити итд
                                                            непосредственно нагрузочное — примерно 20 человеко-часов
                                                        +7
                                                        В яндексе Не пишут сначала тестовый вариант на питон. В яндексе много проектов. Одни на одном, другие — на другом. Мой круг вот вообще на PHP написан. Но это не повод говорить, что в Яндексе пишут приложения на PHP.

                                                        Взяли питонового человека — стали писать «сначала» тестовый вариант на питоне. То, что его в итоге перепишут на C/C++ это еще не факт.
                                                        По большому счету, вообще все равно на чем писать бекенд, так как 20000000 хитов в сутки разделить на 86400 — это получается всего-навсего 231. Даже если считать, что у нас в сутках 10 часов (часы пик и тп) — то это 500 RPS.

                                                        500 RPS с сервера достигается на чем угодно, если руки растут из плеч, даже на PHP, не к ночи будь помянут.
                                                          +1
                                                          Ну мойкруг они не писали, а купили… С командой, а вообще насколько мне известно ПХП в яндексе очень мало.
                                                            –2
                                                            Да, все так. Да, на php мало, потому что в здравом уме на нем врядли кто писать будет, так как язык мерзкий, а технической стороной в яндексе заправляют технические специалисты. Но количество проектов на питоне там немногим превышает количество проектов на PHP, с одной стороны, а с другой — при наличии инфраструктуры и отлаженных средств управления ей — уже все равно на чем писать бекенды. Есть проекты на перле, например. Никто же не говорит, что «яндекс написан на перле».
                                                              +2
                                                              я вообще ничего не говорю :). Но не надо холивара насчёт мерзости языка. Я умоляю вас. Если ума не хватает как заставить нормально работать, это еще не причина кричать, что язык мерзкий.
                                                                0
                                                                Насчет ума — спасибо, повеселили. Наверное, PHP это для исключительно умных людей. Интересно, на чем разрабатывают веб-приложения все остальные.
                                                                  0
                                                                  нет разницы на чем писать — главное иметь голову на плечах. И уже и примеры приводили и все остальное — нет же люди утверждают что всё равно. Ну… продолжайте. Мне вот разницы нет на чём писать — хоть ПХП, хоть Руби, хоть Перл, почти хоть питон, уже почти почти хоть ерланг. Просто не обижайте мой первый коммерческий язык программирования. Очень обидно слышать.
                                                                    +2
                                                                    Разница между языками есть. В трудоемкости разработки. В выразительности. В количестве в дефектов (статическая типизация — меньше, динамическая — больше). В производительности (таки да). В наличии и количестве необходимых библиотек. В качестве этих библиотек. В легкости разрабатывать масштабируемые решения. В стоимости и наличии необходимых специалистов для разработки и поддержки.

                                                                    Если бы разницы не было — то все бы так и писали на С, и всех бы все устраивало.

                                                                    Обидеть язык программирования невозможно, он не человек. А уж если человек действительно пишет на многих языках, то врядли его может задеть упоминание, что какой-то язык — так себе язык. Тем более, что если человек на всех этих языках пишет, то не может не видеть, что они ВСЕ — так себе, в том или ином. Ну, правда есть языки от которых пованивает, но замечаешь это не сразу, а есть такие, от которых просто смердит.
                                                                      +1
                                                                      Еще раз доношу до вас свою точку зрения — если уметь — то нет разницы на чем писать. Уже много раз приводились примеры фасебука и википедии, но все равно люди продолжают кричать — я бы никогда не выбрал пых и мускуль для высоконагруженных проектов. Да там много что не на пыхе и мускули там наполовину своими патчами прошити, но и любой другой язык из коробки не справился бы с такими нагрузками.
                                                                        +3
                                                                        Я в самом первом сообщении написал, что «с другой — при наличии инфраструктуры и отлаженных средств управления ей — уже все равно на чем писать бекенды». Я не сомневаюсь, что на PHP можно написать нагруженный проект. Про MySQL я вообще ни слова не сказал — это вы с самим собой спорите, что ли?

                                                                        Но языки, инструменты, все разные. На одних проще сделать качественный и расширяемый продукт, на других это менее просто.

                                                                        И на последок таки донесу свою точку зрения — разница на чем писать есть. И разница в результате в зависимости от выбора инструментария — тоже есть. И от умения это, зачастую, никак не зависит, если, конечно, вы в необходимые умения не зачисляете исправление и переписывание выбранной платформы.
                                                                          0
                                                                          Digg — «написан» на LAMP-е
                                                                            +2
                                                                            а что дигг не могли начинать делать горе-программеры? :)
                                                                            0
                                                                            >Но языки, инструменты, все разные. На одних проще сделать качественный и расширяемый продукт, на других это менее просто.

                                                                            Понятия «просто», «проще» и т.п. вы как оцениваете? Трудозатраты (человеко-часы) или еще как? Если трудозатраты, то оцениваете ли разницу в стоимости человеко-часа для разных языков, на какую квалификацию ориентируетесь?

                                                                            >И на последок таки донесу свою точку зрения — разница на чем писать есть. И разница в результате в зависимости от выбора инструментария — тоже есть.

                                                                            Конечно есть, и зачастую язык, «от которого смердит», является оптимальным выбором для достижения необходимого результата ;) Не смотря на выразительность, красоту и элегантность других языков, а зачастую и не смотря на их производительность и т. п. Главное какой результат нужен, и выбор среди каких средств для его достижения есть в рамках бюджета/срока
                                                          –4
                                                          Приложения сразу надо писать для работы на нескольких серверах одновременно типа map reduce, тогда быстрее будет, особенно если задача сложная.
                                                            0
                                                            Это не вычисления, это обычный сайт, типа хабра.
                                                            map reduce это больше в сторону обработки данных.
                                                              +1
                                                              Если типа хабра — то кеш и все из него выдавать, динамика убьет при такой посещаемости любой серв
                                                            +3
                                                            apache исключаем сразу.
                                                            +10 за nginx
                                                              –3
                                                              чего это вдруг?
                                                                0
                                                                слишком тяжел для таких нагрузок он
                                                                  0
                                                                  У нас апач и соотв. модуль для него сейчас до 8000 запросов\сек отдаёт. Что я делаю не так?
                                                                    0
                                                                    вы все делаете прекрасно — супер просто
                                                                    однако нгинкс легче просто напросто и жрет меньше ресурсов, которые можно отдать под базу или еще что-то
                                                                      0
                                                                      При разработке апача приотритетом было соблюдение стандартов, а не скорость (а зря я считаю), так что товарищ скорее всего прав.
                                                                        0
                                                                        Что значит скорее всего прав? Вот у меня есть Apache 2.2.10, вот у меня куча самописных модулей, вот кластер из машин и вот порядка 8000 обрабатываемых запросов в секунду без проблем. Так что он, очевидно, не прав.
                                                                          +1
                                                                          Наверное под nginx обрабатывало при той же загрузке машины 16000-20000 запросов :)
                                                                    +1
                                                                    ну апач это скорее вездеход с тремя наборами разных видов колес и системой динамического регулирования давления в них. а также с убирающимся верхом, несколькими багажниками, отстегивающимися подкрылками, четырьмя видами спойлеров (в базовой комплектации), кучей фар, кенгурятником, лебедкой и др. и пр.

                                                                    nginx же — _просто_ _спортивный_ _автомобиль_. без излишеств. даже местами непокрашенный, да и фар почти нет. чисто заточен под свою основную функцию.
                                                                      0
                                                                      ну и пусть себе просто_спортивный развозит пассажиров по вездеходам, а дальше уже на них… не? )))
                                                                        0
                                                                        ну мона и так :))
                                                                        слышал так делают, ага.
                                                                        но самому не приходилось… у меня всё монгрелы с nginx'ами в основном :)
                                                                          0
                                                                          А смысл? Немного выиграете в скорости разработки, проиграете на оборудовании.
                                                                  • UFO just landed and posted this here
                                                                      +3
                                                                      windows и не планируется.
                                                                      Насчет C/C++ — разница в скорости с современными компиляторами(Intel C++) невелика, а вот программы надежнее (с STL, exceptions, Boost/Poco — меньше места для ошибки)
                                                                      • UFO just landed and posted this here
                                                                          0
                                                                          Высоконагруженность бывает разная :-)
                                                                          Мне кажеться биллинг Masterhost-а это десятки тысяч хитов в день, а не миллионы.

                                                                          Участвовал давно я на одном Java-проекте, где 4-х процессорный сервер загибался от 10-и пользователей, лазящих по форуму.
                                                                          Но это конечно неэффективная реализация.
                                                                            +2
                                                                            «Реальность еще страшнее» (с), биллинг, пусть даже Мастерхоста — далеко не такой хайлоад, как кажется со стороны.

                                                                            Сколько у .m клиентов? Доменов .ru — 88000. Возьмем за число клиентов — 200000. Кругло. С запасом.

                                                                            Допустим, что каждому клиенту нужно попасть в _биллинг_ — 2 раза в неделю. Итого — 8 раз в месяц. Опять-же, округлим до 10 раз. Получаем 2000000 заходов в биллинг в месяц, 500000 в неделю, 71000 в день, 3000 в час, 50 в минуту и меньше 1 юзера в секунду.

                                                                            Это много? Нет, это очень мало :)
                                                                            Даже если этих самых юзеров в минуту будет не 50, а 500, да даже 1000. Это все равно очень далеко до объемов не то, что гугла, а даже хабра.

                                                                            Естественно, все рассчеты — очень примерные и врятли имеют отношение к реальности. Просто биллинг — сугубо техническая вещь, которая нужна клиентам не так часто. Я бы сказал совсем не часто. Чего там делать-то каждые 15 минут? Я думаю, 80% клиентов вообще заходят туда раз в месяц, оплатить хостинг на следующий месяц. Все.

                                                                            А вот нагрузки тикетницы или главной сайта .m уже куда интереснее :)

                                                                              +1
                                                                              я туда раз в три месяца захожу, хотя крутится 9 сайтов =(
                                                                                0
                                                                                Согласен с автором предыдущего сообщения.
                                                                                0
                                                                                Это, что за форум (движок) такой был? Самопал?
                                                                            –16
                                                                            Хе-хе, а родной язык компов вообще — язык ассемблера.
                                                                            • UFO just landed and posted this here
                                                                                –15
                                                                                Да-да, на перфокартах:)
                                                                                  +2
                                                                                  Нет, уже давно не на перфокартах
                                                                            +5
                                                                            а может стоит обратить внимание на эрланг?
                                                                              –8
                                                                              Он же страшно тормозной, вроде?
                                                                                +3
                                                                                Именно поэтому его использовали для создания одной из частей чата facebook :)
                                                                                  +2
                                                                                  Ok, посмотрел. Я ошибался. Он действительно заметно быстрее обычных скриптовых языков типа питона, перла и руби, но до джавы и c++ ему всё-таки далеко. Если уж говорить о функциональных языках (которым эрланг, насколько мне известно, является), то лучше уж выбрать хаскелл.
                                                                                    +1
                                                                                    Я бы не сказал, что Эрланг быстрее кого-то в принципе. Он быстрее и надежнее в некотором классе задач. Хотя, наверное, для веба он быстрее на всех задачах из-за специфики веба. Кстати, там эти фэйсбучники еще и те самые плюсы (не к ночи будь помянуты) используют. Так что автору есть куда копать :)

                                                                                    ЗЫ. А почему именно хаскелл? Он для веба насколько актуален, в плане наличия фреймворков, инфраструктуры и т.п. Тот же самый разбор POST-запроса и прочее, биндинги к базам. Я с этой стороны просто на него никогда не смотрел.
                                                                                      0
                                                                                      В Гугле тоже значительная часть веб-сервисов на C++ написана.

                                                                                      Хаскелл — потому что с одной стороны достаточно быстр, а с другой стороны хорошо продуман (на код написанный на оКамле я смотреть без ужаса не могу). Вроде бы всё что нужно (библиотечки для веб, БД) для него есть, хотя подробно я этот вопрос не изучал…
                                                                                        0
                                                                                        Хаскель может и продуман, но он не используется в тамком продакте, как Ерланг. Я просто видел на фотографиях те АТСки которые обсчитывает Ерланг — вот это реально хайлоад.
                                                                                        +1
                                                                                        Haskell для веба — HAppS. С привязкой к БД тоже вроде всё нормально. На высокопроизводительный сервер на Haskell будет интересно посмотреть (без иронии).
                                                                                        В любом случае, что Erlang, что Haskell для таких задач надо уметь готовить — чуда не случится.
                                                                                          0
                                                                                          > Haskell для веба — HAppS.

                                                                                          HAppS форкнули, потому что самый главный его разработчик занят теперь чем-то другим. Форк называется Happstack.

                                                                                          > На высокопроизводительный сервер на Haskell будет интересно посмотреть (без иронии).

                                                                                          Hyena? :)

                                                                                        0
                                                                                        Эрланг в отличии от Хаскеля заточен исключительно под многопоточность, за счет этого и происходит выигрыш при больших нагрузках.
                                                                                        • UFO just landed and posted this here
                                                                                            0
                                                                                            Эрланг создавался для многопоточности, а к Хаскель могопоточность прикручивалась.
                                                                                            В это разница.
                                                                                      +2
                                                                                      www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-1/

                                                                                      там три части истории, рекомендую прочесть
                                                                                      не совсем о скорости но все равно интересно
                                                                                        0
                                                                                        Действительно, интересно. Спасибо.
                                                                                    +16
                                                                                    Вам надо перестать думать о языке реализации и сразу подумать о масштабировании всего вашего хозяйства. Если это веб-проект то со временем нагрузки будут только расти, и вы очень быстро перейдёте грань, где преимущества в скорости С++ (пусть и в несколько раз) на интерпретируемыми языками уже не будут ничего решать. А сложностей разработки и масштабирования приложений на С++ больше. Да и почему php обязательно? Можно выбрать ruby или python, или даже эрланг(тем более с его возможностями по масштабированию). К тому же непонятно, какой характер носит приложение. Если оно делает какие-то тяжёлые вычисления, тогда имеет смысл думать о их реализации на С++ в виде процесса демона на бэкенде. А отдавать и генерировать фронтенд на С++ не стоящая свеч идея.
                                                                                      +1
                                                                                      PHP просто потому что у меня с ним опыта больше, чем с Ruby/Python. При правильной настройке эти языки показывают схожую производительность.

                                                                                      Приложение — обычный сайт, никаких вычислений.

                                                                                      Да, безусловно грань есть, на мой взгляд на уровне порядка 15-30кк хитов в день.

                                                                                      Однако не могу сказать что масштабирование C++ сложнее того же PHP. Поставить 5 серверов за reverse proxy — так же просто.

                                                                                      Одно дело ставить прокси допустим только через 2 года, а другое — начинать добавлять серверы по 1 шт в месяц уже через пол года.
                                                                                        +1
                                                                                        Ну да, производительность то схожая, но писать на тех же рельсах поприятнее. :)

                                                                                        Я просто к тому, что если всё так обычно, то зачем изобретать велосипед. Если бы использование С++ экономически оправдывалось мы бы в вебе чаще о нём слышали :). Тем более, скорее всего узким местом будет, как всегда, база данных.
                                                                                          0
                                                                                          Кому на чем удобнее, тот на том и пишет )

                                                                                          Так в этом и идея, что база только для долговременного хранения и редких сложных запросов.
                                                                                          Все простое — внутри моментально получается из памяти.
                                                                                            +1
                                                                                            Ну тогда всё равно же придёться использовать какой-то распределённый кеш типа memcached, иначе как быть с обменом и актуальностью данных между серверами.
                                                                                            +2
                                                                                            C++ модули используется во всех нагруженных продуктах (Amazon, Facebook, Google, etc). Другое дело что мало где всё пишут на C++.
                                                                                            0
                                                                                            С добавлением серверов тоже не все так просто. Можно зарытся в SQL, причем не в сравнительно легко масштабируемый SELECT, а именно в инсерты, гораздо раньше чем понадобится второй сервер под фронтенд.

                                                                                            Все зависит от специфики сайта.
                                                                                              +3
                                                                                              есть опыт с ПХП и 2.5м хит в день. 2 веб сервера, 1 БД сервер
                                                                                              у вас проект сразу до такой нагрузки прыгнет? думаю пробемы можно решать по мере поступление.
                                                                                              и просто например покупать еще один сервер, который обойдется дешевле чем разработчик на С++
                                                                                                +2
                                                                                                + грамотное кеширование, вполне хватет :)
                                                                                            +1
                                                                                            думаю затраты на c++ не оправдают себя
                                                                                            Если обычная вебапликуха — подойдет и php. Если что то более серьезное — я бы смотрел в сторону java (по сравнению с с++ надежность будет значительно выше, разработка дешевле, сапорт проще). Ну и в любом случае изначально рассчитывать на кучу серверов.
                                                                                            Да и с .net есть конкретный опыт, когда система под нагрузочными тестами вполне выдерживала подобную нагрузку.
                                                                                              +1
                                                                                              board.rt.mipt.ru/ на плюсах написано
                                                                                              а по поводу производительности — грамотное кэширование и прокси-сервера и так спасают. Логика-то не сильно нагружает проц, больше база.
                                                                                                –1
                                                                                                Да, именно по этому я не планирую даже memcached, а кешировать внутри C++ приложения с минимальной нагрузкой на БД.

                                                                                                А по поводу форума — Requests per second: 22.06 [#/sec] при 100 запросах параллельно, куда-то там у них упирается.
                                                                                                  0
                                                                                                  я просто к тому, что на там же железе можно было поднять более производительное приложение. А на чем уже поднимать — тут не критично, поэтому я бы сконцентрировался на надежности и масштабируемости.
                                                                                                    +5
                                                                                                    Далеко не факт, что вам получится сделать быстрее, чем memcached. В конце концов, это серьезная разработка, в нем немало алгоритмов оптимизации. Зачем велосипедить?
                                                                                                      +1
                                                                                                      велосипедить однозначно не нужно. ни единый серьйозный веб-проект без мемкеша не обходится. да и самый серьйозный не обходится — у фейсбука под тысячу одних только мемкеш серверов.
                                                                                                  0
                                                                                                  А на чем еще можно писать такое? :) Разве что на асме :)
                                                                                                    –1
                                                                                                    Да вы, батенька, мазохист!

                                                                                                    Без обид, но уж больно долго вы будете ЭТО создавать.
                                                                                                      0
                                                                                                      Скорость разработки на C++ не более чем в 2 раза меньше чем на PHP, естественно если работают люди которые знают C++ :-)
                                                                                                        +1
                                                                                                        Смотря задача какая. С набором готовых классов для веба писать можно даже быстрее чем на PHP.
                                                                                                          –2
                                                                                                          За счет чего выигрыш будет? Действительно интересно. Естественно при условии, что или набор готовых С++ классов реализует базовую функциональность PHP и «ни цента» больше, или с набором аналогичных классов для PHP, аналогичных по функциональности IDE и т.п.

                                                                                                      +2
                                                                                                      собственный опыт
                                                                                                      два сервера ксеоны по 4 гига памяти и база на третьем

                                                                                                      nginx+fast-cgi+php+mysql

                                                                                                      без мемкеша держали нагрузку в 7.5к запросов в секунду… и ничего… масштабировалось это дело просто подкидыванием еще одного сервера под fast-cgi и все :)

                                                                                                      не самое лучшее решение, однако нам хватило
                                                                                                        0
                                                                                                        А opcode cache?
                                                                                                        Это со статикой 7.5к или только к PHP?
                                                                                                          0
                                                                                                          специфика приложения такова что статики нет вообще — только динамика- при каждом запросе 5-6 запросов в базу для выяснения данных и тп…

                                                                                                          opcode cache — никакого :) не было нужды ставить просто… держат и хорошо (не верный подход, но не буду это обсуждать тут)

                                                                                                          хотя потом на другом проекте практически такой же нагрузки был поставлен eAccelerator, что снизило нагрузку практически в 1.5 раза
                                                                                                            0
                                                                                                            статика — имею ввиду картинки, JS, css…
                                                                                                              0
                                                                                                              я понимаю, что вы имеете ввиду под статикой. данный сервер не обрабатывал эти запросы. у него была задача сбора статистики и на основе присланной информации отдать ответ динамический.
                                                                                                        • UFO just landed and posted this here
                                                                                                            0
                                                                                                            Каждая версия скриптов выкладывается в отдельную папку на всех машинах, вебсервер смотрит в папку /default/, которая линкуется на текущую версию. При написании новой версии нужно тольок синхронно обносить симлинки на всех машинах, например с помощью cexec, работает не в пример быстрее чем обновление кеша NFS.
                                                                                                              0
                                                                                                              а мы сделали еще проще…
                                                                                                              есть тестовый сервер где обкатываются скрипты — как только дается добро на установку на продакшн скрипты выкладываются на один «главный» условно сервер — остальные растаскивают по rsync
                                                                                                              0
                                                                                                              А сколько ядер на каждом ксеоне? По одному?
                                                                                                                0
                                                                                                                двух ядерные насколько я помню конфиг сервера
                                                                                                              +9
                                                                                                              >Имел ли кто-либо из читателей опыт разработки веб-приложений на С++?

                                                                                                              эээ… www.insight-it.ru/?
                                                                                                              линкедин, например, 1000 (а то и поболее в моменты макс. загрузки — 40 миллионов просмотров страниц в день) в секунду держит. Практически всё Java.

                                                                                                              зы вы вроде бы не назвали ни одной особой причины(=сложной задачи) по которой стоило бы предпочесть именно плюсы, а не java
                                                                                                                0
                                                                                                                Кто-то на Хабре писал, что в Youtube самые критические места написаны или на c++ или вообще на asm, правда ли — не знаю :)
                                                                                                              • UFO just landed and posted this here
                                                                                                                  +2
                                                                                                                  А в чем проблема? Цель поста достигается, в комментах — полезные цифры по производительности конкретных систем, которые склоняют меня к варианту PHP+APC.
                                                                                                                    0
                                                                                                                    на счет акселератора я бы попробовал разные варианты и сравнил цифры для себя самого…

                                                                                                                    кстати если будете юзать мускл — юзайте innodb предварительно настроив его правильно — адская машина если дать ей 32 гигабайта памяти :)
                                                                                                                      0
                                                                                                                      APC выбран не только из-за кеширования опкода, он еще и данные кэширует намного быстрее memcached по тестам.
                                                                                                                        0
                                                                                                                        да? а дайте линк на эти тесты…
                                                                                                                        хочу видеть как APC позволяет делать выборку по ключу из любого размера кеша за статическое время

                                                                                                                        может и себе заюзаю его…
                                                                                                                          0
                                                                                                                          www.mysqlperformanceblog.com/2006/08/09/cache-performance-comparison/

                                                                                                                          98k vs 12k

                                                                                                                          Ограничение понятно — apc не разносится по кластеру, а memcached — разносится.
                                                                                                                            0
                                                                                                                            use APC Cache for single node applications If you have just one web server or your data set is small so it fits in memory in each of the servers APC Cache may be the most efficient way for you to cache the data.

                                                                                                                            Use Memcached for large scale applications If local node cache is not large enough to cache good amount of data caching on network by using memcached is very good way to go.

                                                                                                                            так что все зависит от архитектуры вашего приложения…
                                                                                                                      0
                                                                                                                      По опыту — я бы задумался о PHP+xCache+MemCached
                                                                                                                      1) xCache — несколько быстрее нежели eA
                                                                                                                      2) eA — существенно быстрее APC
                                                                                                                      3) ни один из них не вытягивает нормально множество чтений из памяти
                                                                                                                      4) изначально расчитывать на н-дцать серверов бекенда + ка-цать серверов Memcached + эль-цать серверов MySQL.

                                                                                                                      Я ведь верно понимаю, что первоочередная задача — минимизация времени простоя?

                                                                                                                      П.С. memcached не кеширует opcode, ага ;)
                                                                                                                        0
                                                                                                                        П. 1) и 2) сильно спорны. В интернетах утверждают, что результаты сильно зависят от скриптов, к которым опкод-кэшеры применяются.
                                                                                                                          +1
                                                                                                                          Согласен, я зря безапелляционно пропагандирую превосходство xCache. Переформулирую: я не сталкивался с набором PHP файлов, на которых обратное было бы верно.
                                                                                                                      • UFO just landed and posted this here
                                                                                                                          0
                                                                                                                          1) Железо — сколько нужно будет :-)
                                                                                                                          Заказчик изначально планировал 10к$ в месяц на железо, но имхо это перебор :-)

                                                                                                                          2) Затраты на разработку — это неизвестная переменная :-) В данном случае, это не самое главное.

                                                                                                                          3) тут реальное веб-приложение, допустим типа хабра, явно не пустая страничка.
                                                                                                                          • UFO just landed and posted this here
                                                                                                                              –3
                                                                                                                              1. Это не гиблая, а светлая идея :-) Один сервер намного эффективнее, чем куча серверов с синхронизацией.
                                                                                                                              2. Там писалось, что потратить в 3 раза времени чтобы реализовать на С++ — не проблема.
                                                                                                                                +5
                                                                                                                                Один сервер намного эффективнее,

                                                                                                                                особенно когда

                                                                                                                                а) он таки кончится, а приложение (surprise!!) не масштабируемое, потому что «лучше один большой сервер с C++, чем много маленьких с perl/ruby/erlang»
                                                                                                                                б) произойдет отказ железа. Единственного ключевого сервера.
                                                                                                                                  –1
                                                                                                                                  а) может и не наступить никогда, а если и наступит — nginx в виде прокси спасет (если приложение хоть чуть-чуть готово к этому) )
                                                                                                                                  б) согласен
                                                                                                                                    0
                                                                                                                                    а) и сразу ВНЕЗАПНО необходимость синхронизации, от которой вы сейчас старательно пытаетесь уйти.

                                                                                                                                    или я вас не понял и вы хотите C++ ного демона прямо голым жопом выставить в сеть?
                                                                                                                                      0
                                                                                                                                      В варианте 2 — да :-) А в чем проблема?
                                                                                                                                      Но конечно вариант 1 по идее не намного медленнее (через nginx)
                                                                                                                                      0
                                                                                                                                      … продолжение мысли

                                                                                                                                      а потом в случае нужды закрыть nginx-ом?
                                                                                                                                      0
                                                                                                                                      > а) он таки кончится, а приложение (surprise!!) не
                                                                                                                                      > масштабируемое, потому что «лучше один большой
                                                                                                                                      > сервер с C++, чем много маленьких с perl/ruby/erlang»

                                                                                                                                      Производительности какого из компонентов железа по-Вашему может не хватить?

                                                                                                                                      Каким образом вы предлагаете производить обмен данными между «маленькими серверами с „perl/ruby/erlang“?
                                                                                                                                      Через базу? Тогда как вы гарантируете, что „не кончится“ сервер под базу? Масштабирование с помощью Partitioning/replication? Использовать memcached? Как решать проблему актуальности кэша при изменении данных в базе?
                                                                                                                                      Если не через базу, то как вы будете осуществлять обмен данными между серверами? Как обеспечить синхронизацию одновременно между несколькими серерами?

                                                                                                                                      Понимаете, всё зависит от типа задачи. Если у вас „сайт вроде Хабра“, где запросов на чтение сильно больше запросов на запись, и нет интерактивности в реальном времени, то возможно большинство из прелестей синхронизации вам удастся избежать. Если же вам требуется болше интерактивности, то это может стать серьёзной проблемой. Представьте себе банальный чат на нескольких серверах без использования базы.

                                                                                                                                      Вот и делается попытка избежать всех этих прелестей, попытавшись уместить всё в одном срервере. Гораздо проще масштабировать по количеству ядер/объёму памяти, чем по количеству серверов.
                                                                                                                                      • UFO just landed and posted this here
                                                                                                                          0
                                                                                                                          Можно посмотреть в сторону OCaml-а/Ocsigen, который не сильно проигрывает в производительности Сям (будучи откомпилённым). Но параллелится будет легче, ФП всё-таки.
                                                                                                                            0
                                                                                                                            Специфические функциональные способности к распараллеливанию у OCaml нулевые — потоки в нём всегда захватывают глобальный мьютекс. А если использовать процессы, то свойства языка уже без разницы. Скорость линейного исполнения хорошая, да (и именно про это была статья на eigenclass, домысливать не надо ;-) ).
                                                                                                                          • UFO just landed and posted this here
                                                                                                                            • UFO just landed and posted this here
                                                                                                                                0
                                                                                                                                > Потому что когда по хитам в сутки вы дойдете до потолка возможностей
                                                                                                                                > вашего сервера, все равно придётся делать его масштабируемым.
                                                                                                                                > Поэтому лучше заложить это в архитектуру изначально.
                                                                                                                                Где, по Вашему мнению, будет узкое место (т. е. я понимаю что без знания точной специфики приложения, но хотя бы варианты)? Т. е. мощности какой части железа может не хватить?
                                                                                                                                • UFO just landed and posted this here
                                                                                                                                    0
                                                                                                                                    На что именно при этом будет расходоваться большая часть процессорного времени? Если логика простая, то чем именно будет занят процессор?
                                                                                                                                0
                                                                                                                                Я бы выбрал вариант с memcached. Оставляет больший зазор для масштабирования.
                                                                                                                                  +6
                                                                                                                                  Все очень сильно зависит от задачи.
                                                                                                                                  Может быть C++ действительно очень оправдан (а то и некий аппаратный блок!).
                                                                                                                                  Но в общем случае, думаю, что затраты на содержание и поддержку (совокупная стоимость владения) в случае C++ сведут на нет все его преимущества. Я к тому, что лучше использовать специализированные технологии не только из за их технических параметров, но и иметь в виду организационные моменты. Поддерживать ресурс на C++, отслеживать баги и утечки памяти (а без них не получится в более-менее сложном проекте) намного дороже и дольше, чем использовать предназначенные для этого технологии.

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

                                                                                                                                  P.S. И разумеется — архитектура, архитектура и еще раз архитектура.

                                                                                                                                  P.P.S. Да, в определенных случаях, железо докупать действительно дешевле, чем поддерживать очень быструю и очень сложную систему. Плюс это повышает надежность (чем сложнее система, тем больше вероятность, что «что-нибудь где-нибудь да сломается»).
                                                                                                                                    +3
                                                                                                                                    Писал на плюсах в 2000 году банерную систему. 3 миллиона показов в сутки — не вопрос. Apache, MySQL и 300MHz какой-то проц )
                                                                                                                                      0
                                                                                                                                      надо использовать кеширование + десяток серверов + распределение базы (разделение) + оптимизацию программного кода вне зависимости от серверного языка. поставьте изначально примерно такую задачу и тут такое начнётся по поводу приоритета языков, что мама не горюй )))
                                                                                                                                        +4
                                                                                                                                        берёте ПЛИС, программируете её и делаете плату, которую вставляете в сервер. с нагрузкой справится 1 машина =)
                                                                                                                                          –1
                                                                                                                                          Неа, если бы все было так просто, то nginx отдавал бы неограниченный трафик с 1мб статики, которая помещяется в кеше :-)
                                                                                                                                          На практике все еще упирается в сеть.
                                                                                                                                            +2
                                                                                                                                            Отличная идея! Verilog, как язык веб программирования! :-)
                                                                                                                                            0
                                                                                                                                            Лавпланета так и написана, если не изменяет память.
                                                                                                                                              +8
                                                                                                                                              Есть некоторый опыт разработки высокопроизводительных систем.

                                                                                                                                              Считаю, что при отсутствии сложной вычислительной работы, т. е. если требуется только простая логика + операции с хранилищами данных (диск/БД) вы сможете добиться желаемой производительности даже на одном ядре класса Core 2.

                                                                                                                                              Apache не годится, как и различные APP-сервера. Надо использовать предоставляемые системой средства для одновременной обработки большого количества запросов I/O (epool, kqueue, IOCP). Разница например между C# и C++ будет не очень велика, скорее будет отличаться потребление памяти, ну и возможно как-то могут сказаться паузы на GC. С Java немного сложнее (по крайней мере раньше так было, как сейчас точно сказать не могу, надо разбираться) в том смысле, что SE API не предоставляет эквивалента требуемым системным средствам.

                                                                                                                                              Вообще язык реализации можно брать любой (с учётом ранее сказанных требований), естественно делая поправку на разницу примерной производительности с C/C++. Тут дело личных предпочтений (кому-то и на С++ может быть писать комфортнее и быстрее).

                                                                                                                                              Преимущество подхода в том, что можно уместить всё на одной машине, а это очень хорошо, если запросы от разных пользователей (сессии) требуют обмена между собой информацией. Естественно надо готовиться, что железо будет стоить приличных денег (потребуется наращивать много памяти и возможно ядер, дисковый массив, если потребуется).

                                                                                                                                              Может также возникнуть проблема с тем, что системе будет сложно одновременно работать с очень большим количеством соединений. В этом случае можно распределить их по «маленьким» прокси, которые будут просто сериализовать данные с нескольких соединений в одно и передавать их серверу.

                                                                                                                                              Да, и подумайте ещё раз, перед тем как начинать разработку: точно ли у вас не будет узкого места с БД, потому что если будет, то все силы надо отправлять туда, а остальное уже вторично.
                                                                                                                                                0
                                                                                                                                                meshok.ru — php eAccelerator Mysql

                                                                                                                                                250 — 400 запросов в секунду на динамике.
                                                                                                                                                Все работает.
                                                                                                                                                  0
                                                                                                                                                  Если я правильно понял, то вам можно связаться с Иваном Сагалаевым. Я восторгался его мужеством :) когда читал о том как он решал схожие проблемы на С++
                                                                                                                                                    +3
                                                                                                                                                    Мне дали однажды тестовое задание написать за неделю с нуля вебсервер котороый будет отдавать как минимум 2000 запросов с данными с базы в секунду, на C. Я не понял что они шутили и сделал.

                                                                                                                                                    Им пришлось взять меня но потом через месяца три попросили уйти, на C они ничего на самом деле в конторе не писали. Это было до кризиса конечно.
                                                                                                                                                      +1
                                                                                                                                                      Я написал это к тому, что именно на Си обычно нет смысла писать. Можно и на других языках это сделать, проблема была не в скорости языка, а в правильной работе с базой данных (кэширование, забор данных наперёд, и тд).
                                                                                                                                                      +1
                                                                                                                                                      Лучше писать на Эрланге — на нормальном железе и прямых руках программиста способен держать миллион TCP соединений, мой товарищ когда про это рассказывал аж слюнями истек от восторга. Плюс, будучи функциональным он отлично масштабируется.
                                                                                                                                                        0
                                                                                                                                                        Масштабируется он не столько потому что функциональный, а потому что он задумывался таким :)
                                                                                                                                                          +1
                                                                                                                                                          «Чистота», присущая функциональным языкам, этому только способствует.
                                                                                                                                                        • UFO just landed and posted this here
                                                                                                                                                            0
                                                                                                                                                            Не знаю.
                                                                                                                                                          • UFO just landed and posted this here
                                                                                                                                                              0
                                                                                                                                                              Возможно, я стресс-тест серверов на Эрланге не проводил. Посмотрел пару мануалов и решил, что похоже на правду.
                                                                                                                                                            0
                                                                                                                                                            Как-то так:

                                                                                                                                                            1. Архитектура, должна быть приспособлена к горизонтальному масштабированию, что бы можно было поставить +1 сервер, развернуть там еще один бекенд и вперед, т.к. вертикальное масштабирование имеет разумные пределы.
                                                                                                                                                            2. В качестве фронтенда лучше использовать ngnix он довольно шустро умеет отдавать статику и не плохо справляется с fcgi проксированием.
                                                                                                                                                            3. Модули на c\c++ приятней писать под apache, много документации, большое комьюнити, куча примеров и много почти готовых решений, код которых можно использовать для своего велосипеда.
                                                                                                                                                            5. Лучше использовать fastcgi, он быстрей.
                                                                                                                                                            6. У fastcgi — есть один нездоровый косяк, по мнению многих, до тех пор пока бекенд на другом конце пайпа не отдаст вам данные, все запросы попадают в очередь и ждут смиренно пока не будет удачного ответа или же вылета по таймауту.
                                                                                                                                                            7. Для того, что бы fastcgi выдавал вам максимальные возможности, ваше приложение лучше сделать атомарным, запустить несколько процессов и забить их блоком в тот же ngnix для проксирования.
                                                                                                                                                              0
                                                                                                                                                              по поводу 3, однако один apr чего стоит… =)
                                                                                                                                                              0
                                                                                                                                                              распределенная нагрузка однозначно! ставьтье Piranha и наслаждайтесь!
                                                                                                                                                                +3
                                                                                                                                                                Без разницы на чем писать, главное адекватно. Быдлокод на C++ может быть реально медленнее реализации на PHP/Python/Ruby. А вот, что делать через год два, когда пара основных разработчиков ушла и как эта вся хрень работает никто уже не помнит, совсем другой и более интересный вопрос.
                                                                                                                                                                  0
                                                                                                                                                                  Это скорее вопрос к руководителям проекта, нежели к разработчикам.
                                                                                                                                                                  p.s. Если бы все разработчики об этом думали, был бы мир во всем мире :)
                                                                                                                                                                  +2
                                                                                                                                                                  Если сайта еще нет, то лучше написать его на том языке, на котором вашей команде удобней работать, а затем уже поэтапно решать проблемы производительности. Исключение из этого правила — случай, когда в обработке огромной нагрузки вся соль вашего проекта или если у вас изначально есть серьезная уверенность, что сразу же будет ОГРОМНЫЙ наплыв посетителей.
                                                                                                                                                                  Если вам удобнее писать на C[++] — пишите на нем, таково мое мнение. Неудобно — пишите изначальную версию сайта («прототип») на скриптовых языках.
                                                                                                                                                                  Если это не учебная задача, а реальный коммерческий проект, то при выборе языка определяющую роль играет, по моему мнению, команда программистов или перспективы по ее найму. Я не думаю, что имеющимся в вашем распоряжении программистам абсолютно пофик на чем писать — на C++ или на PHP (для примера). За редким исключением это люди с разной квалификацией (которую не стоит сравнивать напрямую, так как это разные типы языков и подходы к программированию). Это, как правило, люди с разным подходом к решению задач, с разными взглядами на “правильное” программирование. Если говорить о сформировавшихся специалистах. И поэтому, если проект делает не один человек (вы сами), то у вас вряд ли будет возможность свободно выбирать язык программирования — не задумываясь о возможностях имеющихся программистов или о перспективах по их найму (и о зарплатах для них).
                                                                                                                                                                  Так же я уверен, что полностью тупиковый путь пытаться отдать часть работ по сайту, разрабатываемому на C++, фрилансерам или аутсорсить часть проекта внешней команде. В случае же использования «стандартных» для web подходов и скриптовых языков программирования можно часть работы отдать другой команде.
                                                                                                                                                                  А теперь предположим, что поддержка очень высокой нагрузки с самого начала — это критическое условие для проекта. В этом случае нужно разбираться конкретно и индивидуально для каждого конкретного проекта, где именно в нем «бутылочное горло» и как его можно устранить. Не факт, что тут поможет смена языка программирования.
                                                                                                                                                                  Например, если у вас главная сложность в содержательно высокой нагрузке на СУБД, то какая, собственно, разница, сколько микросекунд уйдет на компоновку страницы в C-программе, пока основное время теряется в глубинах СУБД? Тут проблема не на чем писать обработчики страниц/динамических запросов, а как можно ускорить базу. Можно, конечно, и от «стандартной» СУБД отказаться, всю работу перенеся в свой engine. Но это уже получается очень нетривиальный проект. Мне лично такие проекты нравятся, но только когда в них есть реальная потребность. И я понимаю, что это стоит ОЧЕНЬ больших денег и главное — потребует уйму времени.
                                                                                                                                                                  Если же дело не в пропускной способности СУБД или TCP/IP стека, а именно в компоновке страниц, всяком парсинге, возможности “легковесного” кэширования (для которого есть возможность) и т.п., то тогда, конечно, использовать C[++] разумная идея. Можно использовать какой-то легковесный сервер (не apache) или «заготовку» сервера, которая принимает HTTP-запросы и отдает их вашей программе. Для того, чтобы не писать самим и не отлаживать высокопроизводительный модуль приема/раздачи данных по TCP и парсер HTTP. Но, конечно, если есть время, то можно заняться и этим, глядя на исходники лучших open source серверов как на пример хорошей и вылизанной годами реализации.
                                                                                                                                                                    0
                                                                                                                                                                    Я например рекомендовал бы такой набор (ну если деньги несомненно есть на аппаратную платформу :) ) — Itanium + HP-UX + Java.
                                                                                                                                                                    Платформа HP-UX + Itanium обеспечит серьезную производительность и гибкость — не чета преобладающему на рынке железу.
                                                                                                                                                                    Java в свою очередь — высокую скорость разработки, масштабируемость, гибкость, большое количество готовых компонентов и возможностей.
                                                                                                                                                                      0
                                                                                                                                                                      Есть бенчи Itanium vs система аналогичной стоимости на C2Q на Java?
                                                                                                                                                                        0
                                                                                                                                                                        1. Итаниумы можно потестить :)

                                                                                                                                                                        2. www.spec.org/
                                                                                                                                                                      +3
                                                                                                                                                                      Стоимость владения проектом на C/C++ (разработка (= цене хороших девелоперов * очень большое время) + сопросождение/поддержка (так же) + отсрочка запуска и зарабатывания денег) очень и очень высока.

                                                                                                                                                                      Так что реально си нужен только в тех проектах, где по другому просто никак вообще. Например, в поисковиках (в некоторых их частях), рекламных системах и проч.

                                                                                                                                                                      Для проектов типа хабра си точно не оправдан.
                                                                                                                                                                        +2
                                                                                                                                                                        Если очень хочется всё таки использовать C/С++, то выделите из проекта самое «горячее» место и вытащите его в отдельного демона. Которого напишите на C. А всю остальную логику проще и дешевле на скриптовых языках.
                                                                                                                                                                          0
                                                                                                                                                                          1) Имеет смысл по максимуму использовать штатные обкатанные решения — тот же Nginx. Он пишется уже много лет и обкатан сотнями инсталяциий под серьезными нагрузками.

                                                                                                                                                                          2) С++ имеет смысл тогда и только тогда, когда вы имеете совсем нетривиальную логику приложения, тем или иным концом упирающимся в математику (например отдавать в реальном времени агрегированную статистику)

                                                                                                                                                                          Для чисто веб проекта( ЖЖ, Хабр, LI, Facebook, whatever) при правильном проектировании основная нагрузка — не на бэкэнде, а чаще на базе. Посему всеми лапами сразу голосую за вариант 4. При желании — см. предыдущий комментарий :)
                                                                                                                                                                            0
                                                                                                                                                                            при правильном проектировании бд — нагрузку можно с неё частично снять, если не заставлять заниматься тем, что у неё не очень хорошо получается. Так, если каждый запрос в бд вынужден что то менять — я бы вообще отказался от реляционной базы (ну только для изменяемых данных, пожалуй) — реализовав все это в демоне на Си (та же бд, только не реляционная и заточенная под конкретную задачу). До сих пор вставка 10-20к рядов в рбд = почти смерть базе. А ведь по сути задача тривиальная.
                                                                                                                                                                            0
                                                                                                                                                                            Написать на С++ можно, но вопрос будет ли такая система гибкая и поддерживаемая. :\
                                                                                                                                                                              0
                                                                                                                                                                              Будет, если правильно спроектировать, как собственно и на любом другом языке программирования
                                                                                                                                                                              +1
                                                                                                                                                                              Имеется опыт РНР сайта с кол-вом хитов в сутки (только PHP, а ещё статика — js, css, картинки: ещё каких 10 лямов в сутки т.к. image хостинг присуствовал тоже) порядка 10 миллионов — один сервер, загрузка порядка 30% по вечерам (Dual Quad Core Xeon 2.4 GHz, 8 GB RAM, 3 x 76 SCSI 15k rmp HDD без райда). Lighttpd + PHP (fastcgi) + xcache + memcache + MySQL с хорошо оптимизированными запросами и кешированием в memcached (как SQL запросы, так и куски HTML — по ситуации).

                                                                                                                                                                              Вообщем общую статистику за 24 часа lighttpd показывал на уровне 23-25 миллионов запросов, более точное распределение я вам не скажу.
                                                                                                                                                                                0
                                                                                                                                                                                Спасибо, ценная инфа.
                                                                                                                                                                                  0
                                                                                                                                                                                  тоже засейвил конфиг :)
                                                                                                                                                                                  0
                                                                                                                                                                                  видел полно PHP сайтов, которые возможно сделаны криво, и которые совершенно недержали нагрузку в виде динамической генерации контента (например photosight.ru). С другой стороны раз Psih пишет, что 25 млн. запросов держал, то нет оснований не верить.

                                                                                                                                                                                  Из своего опыта могу сказать, что такую проблему решали так (правда давно, 2002 год):
                                                                                                                                                                                  — 2 Apache-сервера только страницы отдают
                                                                                                                                                                                  — 2 сервера (БД + application) генерят «практические» статические HTML страницы и подкладывают их на 2 первых
                                                                                                                                                                                  — БД с которыми «работали» посетители тоже прекомпилировались до вида плоской таблицы
                                                                                                                                                                                    +1
                                                                                                                                                                                    1000 RPS это не так много (если речь о dedicated сервере), и легко достигается, например, на питоне.
                                                                                                                                                                                    Проблема — в базе, обращение к базе просаживает производительность сразу на порядок, а для тяжелых
                                                                                                                                                                                    запросов — на два и более. Как понимаете, эта константа от языка не зависит, и потому, делать приложение на
                                                                                                                                                                                    C++ нет никакого смысла вообще. Если посмотреть на тесты, то:

                                                                                                                                                                                    Ocsigen — 4500 — 5800 RPS (core duo что-то там)
                                                                                                                                                                                    YAWS на таком железе будет где-то 2500 — 2800 RPS
                                                                                                                                                                                    Python (мерял на нашем фреймворке) — 480 (без memcached) — 1700 (c memcached)

                                                                                                                                                                                    При том, что правильно написанные http приложения могут естественным образом масштабироваться —
                                                                                                                                                                                    то еще раз, писать на C++ не имеет смысла.
                                                                                                                                                                                      0
                                                                                                                                                                                      Как то необходимо было переписать небольшой код, который очень порядочно нагружал сервер, PHP просто заваливал сервак (проц 100%), модуль для nginx на C++ освободил сервер, загрузка проца упала до 0.1%. Кол-во отдаваемых данных возрасло в несколько тысяч раз. Да и на C++ реально писать почти как на PHP, хотя для этого потребуется как вариант свою плаформу.
                                                                                                                                                                                        –3
                                                                                                                                                                                        Я за С++ однозначно. Если скорость в приоритете конечно.
                                                                                                                                                                                        Про масштабируемость — какую заложите архитектуру, так и расширять получится в будующем.
                                                                                                                                                                                        Имхо, даже не особо грамотный подход СИ кодера обойдет по скорости любой скриптовый язык.
                                                                                                                                                                                        Ведь все ресурсы компа в ваших руках!
                                                                                                                                                                                          +1
                                                                                                                                                                                          Имел счастье делать микс С++ memcached с генерацией данных на пхп
                                                                                                                                                                                          Как говориться — если времени мало а буста хочется…
                                                                                                                                                                                          нгинкс аксесит С++ демона, он шурстит по кешеду МАЛЕК генеря код от себя, что в кешеде на нашол передает на генерацию в пхп, который коладет это дело в кешед…
                                                                                                                                                                                          При необходимости повторить…
                                                                                                                                                                                          Развитие CacheGraph — где граф работает на С++
                                                                                                                                                                                          Местами в сотни раз быстрее и… если надо что-то изменить — меняем это в пхп и не паримся с более сложной разработкой на Сях…
                                                                                                                                                                                          (ПС — первый запуск показал что в Сях кудато утекают гдето 2-3 метра на запрос… отлов бага занял часа 4… вот по этому и считается что разработка на С долгая и дорогая — писать просто и быстро, и еще потом полгода баги правим :) )
                                                                                                                                                                                            +3
                                                                                                                                                                                            вот не понимаю. они не «куда-то утекают», а вы своими шаловливыми ручонками «куда-то про*бываете». а потом все дружно кричат, что с++ говно, у него память течет! поймите, это не у него течет, а у Вас!
                                                                                                                                                                                              +3
                                                                                                                                                                                              На сях очень просто сделать так чтобы память утекала…
                                                                                                                                                                                              Утечки памяти — самая распространенная ошибка
                                                                                                                                                                                              Самый простой способ — ферментировать себе память.
                                                                                                                                                                                              У меня вообще проблема была другая — менеджер памяти(nedalloc) просто оставлял ее про запас, и в одном месте забыл сделать деструктор виртуальным
                                                                                                                                                                                                +5
                                                                                                                                                                                                >Самый простой способ — ферментировать себе память.
                                                                                                                                                                                                А что такое «ферментировать себе память»? Это как-то связано с брожением? )
                                                                                                                                                                                                  0
                                                                                                                                                                                                  вот и исправляй потом ошибки фоксом :)
                                                                                                                                                                                                  фрагментировать!
                                                                                                                                                                                                  0
                                                                                                                                                                                                  Чтобы пмять не текла, есть средства отладки, на крайний случай можно же просто тупо считать ссылки.
                                                                                                                                                                                                    0
                                                                                                                                                                                                    достаточно установить Software Verification\Memory Validator
                                                                                                                                                                                                      0
                                                                                                                                                                                                      Вы только забыли упомянуть что это 1) windows-программа 2) платная
                                                                                                                                                                                                        0
                                                                                                                                                                                                        уговорили — valgrind
                                                                                                                                                                                                        по мне так — вообще зе бест
                                                                                                                                                                                                  0
                                                                                                                                                                                                  <irony>супер C++ джедай детектед </irony>

                                                                                                                                                                                                    0
                                                                                                                                                                                                    вы мне льстите
                                                                                                                                                                                                      +1
                                                                                                                                                                                                      нет, это (вообще-то) была провокация
                                                                                                                                                                                                +1
                                                                                                                                                                                                1) Стоимость сервера ниже зарплаты программиста, проще купить ещё сервер, чем нанимать ещё программистов
                                                                                                                                                                                                2) К стоимости разработки на языке плюсуйте ещё и стоимость поддержки проекта на этом языке
                                                                                                                                                                                                3) Если вам не хватает производительности на посещаемость в будущем, просто начинайте писать сейчас, когда допишите соответственные мощности будут стоить приемлемо
                                                                                                                                                                                                4) Большую часть времени веб-приложение ожидает данных, чаще всего — из базы. Какая разница на каком языке ждать эти данные?
                                                                                                                                                                                                  –1
                                                                                                                                                                                                  1. очень скользкий момент — крайне зависит от масштабов. Если программа планируется загрузить 1 сервак — то конечно лучше взять 3 и писать на легком языке. Если же 100 — то стоимость ещё 200 серверов явно перешкалит зп нескольких девелоперов… ну и… глобальное потепление и всё такое =).
                                                                                                                                                                                                    0
                                                                                                                                                                                                    От масштабов зависит, да. Но сложная математика — редкость в веб-приложениях, а именно она и даёт большую часть выигрыша при переходе к C++.
                                                                                                                                                                                                      0
                                                                                                                                                                                                      ну вот взять хотя бы escape. В питон-варианте (регулярка) он в 4 раза медленее варианта на Си. И так далее тому подобное =)… Не единой математикой си и с++ шиты +).