Комментарии 264
При таком кол-ве запросов уже не язык спасает, а кол-во серверов, кеширование и т.п.
Это понятно, но все же напарсить 50-100 Мб HTML-я в секунду на интерпретируемых языках нереально(ИМХО), а на C++ — вполне, ИМХО.
есть причины по которым не подходит C#?
Не вижу преимуществ C# перед Java, оба даже с JIT-компиляцией медленнее(хоть и не сильно) правильного C++ кода.
А вот расход памяти меня всегда пугал. Также, у C# ограничения на хостинг (mono не в счет :-) ).
Есть ли у кого примеры Java-приложений, которые выжмут 1000 хитов на одном боксе?
Цена разработки стоит на втором месте, главное это скорость.
Если переходить на несколько серверов, сразу падает скорость/сервер (из-за затрат на синхронизацию и проч.) насколько я понимаю, поэтому и хочется обойтись одним толстым сервером.
А вот расход памяти меня всегда пугал. Также, у C# ограничения на хостинг (mono не в счет :-) ).
Есть ли у кого примеры Java-приложений, которые выжмут 1000 хитов на одном боксе?
Цена разработки стоит на втором месте, главное это скорость.
Если переходить на несколько серверов, сразу падает скорость/сервер (из-за затрат на синхронизацию и проч.) насколько я понимаю, поэтому и хочется обойтись одним толстым сервером.
Есть пример Java приложения выжимющего до 30к соединений на одном боксе. Там правда не Http а Sip но оно структурно похоже.
Есть аналог того же но на шарпе. И даже на с++ есть. И у всех скорость одинаковая.
Так что не язык решает а архитектура.
Есть аналог того же но на шарпе. И даже на с++ есть. И у всех скорость одинаковая.
Так что не язык решает а архитектура.
А можно более конкретно озвучить название Java SIP, которое в состоянии обрабатывать 30k инвайтов в секунду?
Вы же это имели ввиду? Хотя бы как примитивнейший Sip Location?
Очень хотелось бы посмотреть на архитектуру в образовательных целях.
Вы же это имели ввиду? Хотя бы как примитивнейший Sip Location?
Очень хотелось бы посмотреть на архитектуру в образовательных целях.
Название к сожалению озвучить нельзя, ибо NDA. Копайте в сторону NIO (там уже разницы нету, либо свой велосипед либо Apache MINA).
Точто делал я работало именно на совем велосипеде поверх NIO и основной затык был в парсинге текста а не в чем либо другом. И кстати обрабатывало именно инвайты :)
Архитектура — два потока. «Acceptor» и «Proxifier» (ну вот так они назывались в реализации). Первый соответственно принимал на себя подключения и давал на растерзание второму.
Точто делал я работало именно на совем велосипеде поверх NIO и основной затык был в парсинге текста а не в чем либо другом. И кстати обрабатывало именно инвайты :)
Архитектура — два потока. «Acceptor» и «Proxifier» (ну вот так они назывались в реализации). Первый соответственно принимал на себя подключения и давал на растерзание второму.
Я просто тоже связан с этим вопросом.
И никоим образом не могу поверить в 30к/с полноценно обработанных транзакций Sip Location на Java. :(
И никоим образом не могу поверить в 30к/с полноценно обработанных транзакций Sip Location на Java. :(
Я вот тоже одно время был связан с этим вопросом. В результате все написалось на java. Конкретно по ней же. Если вопросы синхронизации свести к минимуму и рассматривать каждый пакет независимо (ака сделать эдакий state machine с минимум синхронизаций) то все будет работать. У нас основной оверхед был на синхронизации 10+к объектов. Памяти правда жралось тоже много, но это были терпимые издержки. Опятьпосмотрите информацию по Mina. Товарищи рассказывают про 40-50к запросов на SMS-шлюз, во что я тоже охотно верю.
Простите конечно за назойливость, но я не вижу там указанных Вами цифр:
mina.apache.org/performance-test-reports.html
Там написано про 25к, но при этом они сравнивают ЦЕЛЫЙ апач и некий "… the AsyncWeb lightweight HTTP server example ....". Наверняка прям в памяти заготовлен ответ, и запрос они могут вообще не разглядывать (хотя беглый взгляд показал, что они их хоть парсят).
Сравнение — чушь несусветная. При этом апач 2.0, а тогда и люди были другие, и сервера тупее.
Более современные версии апача и таких результатов не покажут (только предположение).
Жаль что пруфлинков более адекватных нет. Реально очень интересен мне этот вопрос.
mina.apache.org/performance-test-reports.html
Там написано про 25к, но при этом они сравнивают ЦЕЛЫЙ апач и некий "… the AsyncWeb lightweight HTTP server example ....". Наверняка прям в памяти заготовлен ответ, и запрос они могут вообще не разглядывать (хотя беглый взгляд показал, что они их хоть парсят).
Сравнение — чушь несусветная. При этом апач 2.0, а тогда и люди были другие, и сервера тупее.
Более современные версии апача и таких результатов не покажут (только предположение).
Жаль что пруфлинков более адекватных нет. Реально очень интересен мне этот вопрос.
Уважаемый, я не пытаюсь убедить вас в том что Mina — панацея. Кстати те самые цифры были в презентациях и keynotes на их же сайте (вполне может что и не на офф. сайте. Помню что с выступлений 2006-2007гг. Как вариант на каких либо университетских ресурсах. ). Там один из разработчиков подробно описывал как они делали SMS-gate какая была архитектура и где что и как :)
Если говорить о C#, то лично моё имхо состоит в следующем. C# ограничивает вас в выборе платформы, а это, судя по условиям задачи, один из критичных параметров. От обычного .NET приложения не стоит ждать производительности и, что очень важно, бережного отношения к памяти. IIS, несмотря на рекламу, все-таки не самый скоростной и легковесный сервер, не самый защищенный и т.д. и т.п. А еще это средство жутко будет сковывать вас в выборе технологий и компонентов, которые могли бы облегчить вам жизнь.
В отличие от вышеназванного средства, java проще заставить работать быстро и в практически любой среде. Никаких сопоставительных тестов не проводил, но верю, что это работает быстрее php/python/ruby/etc. Т.е. с java вы получите адаптируемость к нагрузкам, относительную простоту разработки и довольно высокую скорость выполнения кода. Для многих частей системы я бы выбрал эту среду.
Самое главное — понять, что ни плюсы, ни java не помогут вам, если ваша система не будет хорошо спроектированной. Архитектура системы будет иметь больший вес, чем инструментальное средство.
По всей видимости, вам придется делать множество прототипов, долго и кропотливо описывать и обдумывать каждую деталь и только после этого выбирать. Если, например, поиск быстрее заработает на бейсике, то не все ли равно, нравится ли это приверженцам с-+.
Кстати, чуть не забыл, на java написан LinkedIn и делаются SIP решения.
В отличие от вышеназванного средства, java проще заставить работать быстро и в практически любой среде. Никаких сопоставительных тестов не проводил, но верю, что это работает быстрее php/python/ruby/etc. Т.е. с java вы получите адаптируемость к нагрузкам, относительную простоту разработки и довольно высокую скорость выполнения кода. Для многих частей системы я бы выбрал эту среду.
Самое главное — понять, что ни плюсы, ни java не помогут вам, если ваша система не будет хорошо спроектированной. Архитектура системы будет иметь больший вес, чем инструментальное средство.
По всей видимости, вам придется делать множество прототипов, долго и кропотливо описывать и обдумывать каждую деталь и только после этого выбирать. Если, например, поиск быстрее заработает на бейсике, то не все ли равно, нравится ли это приверженцам с-+.
Кстати, чуть не забыл, на java написан LinkedIn и делаются SIP решения.
«IIS, несмотря на рекламу, все-таки не самый скоростной и легковесный сервер, не самый защищенный и т.д. и т.п.»
Хотел бы заметить, что желаемое за действительное выдавать тоже не стоит.
Любой веб-сервер, несмотря на рекламу, все-таки не самый скоростной и легковесный, не самый защищенный и т.д. и т.п.
То, что действительно является аргументом — так это то, что .NET ограничивает в выборе платформы. Остальные доводы ничем не подтверждены. Особенно про простоту разработки.
Хотел бы заметить, что желаемое за действительное выдавать тоже не стоит.
Любой веб-сервер, несмотря на рекламу, все-таки не самый скоростной и легковесный, не самый защищенный и т.д. и т.п.
То, что действительно является аргументом — так это то, что .NET ограничивает в выборе платформы. Остальные доводы ничем не подтверждены. Особенно про простоту разработки.
Почему C# ограничивает в выборе платформы? Чем плох mono и fastcgi?
набежали тролли и заминусовали :)
однако, сборки .net (в том числе и C#) вы можете компилировать в нативный код платформы x86 или ia64 и никакая JIT-компиляция задействована не будет, не уверен, может ли java компилировать код в нативный
попробую предположить, что такой вариант будет не сильно медленнее C++ кода
однако, сборки .net (в том числе и C#) вы можете компилировать в нативный код платформы x86 или ia64 и никакая JIT-компиляция задействована не будет, не уверен, может ли java компилировать код в нативный
попробую предположить, что такой вариант будет не сильно медленнее C++ кода
НЛО прилетело и опубликовало эту надпись здесь
И декодер MPEG2 использует векторизацию в SSE-команды?
© Не верю :-)
© Не верю :-)
НЛО прилетело и опубликовало эту надпись здесь
К сожалению использовать SSE-инструкции и векторизацию — это не одно и то же. То, что они используют SSE автоматически не значит, что выполняется векторизация (или даже что делаются попытки её выполнить). SSE можно использовать и для скалярных вычислений. Для Java это имеет преимущество перед FPU потому, что спецификация Java накладывает довольно сильные ограничения на вещественную арифметику, из-за чего при наличии одновременно float- и double-операций требуется либо переключать точность на FPU, либо вставлять дополнительные чтения/записи в память.
На самом деле и не все С/С++ компиляторы могут хорошо выполнять векторизацию. Обычно славится этим Intel (ну ещё бы, не удивительно!).
Вообще, Java несколько затрудняет выполнение векторизации. Взять хотя бы выполнение проверок на выход за границы массива. Для успешного выполнения векторизации, помимо других условий, требуется сначала избавиться от этих проверок, что в общем случае делается с помощью версионирования циклов (в HotSpot используется схема с так называемой деоптимизацией). А версионирование, к сожалению, в HotSpot пока не сильно мощное.
На самом деле и не все С/С++ компиляторы могут хорошо выполнять векторизацию. Обычно славится этим Intel (ну ещё бы, не удивительно!).
Вообще, Java несколько затрудняет выполнение векторизации. Взять хотя бы выполнение проверок на выход за границы массива. Для успешного выполнения векторизации, помимо других условий, требуется сначала избавиться от этих проверок, что в общем случае делается с помощью версионирования циклов (в HotSpot используется схема с так называемой деоптимизацией). А версионирование, к сожалению, в HotSpot пока не сильно мощное.
> Большинство из них писаны студентами за еду.
*Все* программы, с которыми я сталкивался, на Яве, жрали память, место на диске и тормозили (включая к примеру Zend Studio — ее что тоже студенты писали). Может все-таки дело в самом языке?
А приеденный пример с декодером —может он на си написан и просто обернут в Java-класс?
И человек в комментах пишет, Hello World ест 17 Мб памяти (когда я изучал по учебе java, не по своей воле(, я тоже на этио обратил внимание.
Да и как многоэтажное дерево классов может вообще быть эффективным, а?
Что-то как-то то, с чем я сталкивался, противоречит тому, что вы пишете.
*Все* программы, с которыми я сталкивался, на Яве, жрали память, место на диске и тормозили (включая к примеру Zend Studio — ее что тоже студенты писали). Может все-таки дело в самом языке?
А приеденный пример с декодером —может он на си написан и просто обернут в Java-класс?
И человек в комментах пишет, Hello World ест 17 Мб памяти (когда я изучал по учебе java, не по своей воле(, я тоже на этио обратил внимание.
Да и как многоэтажное дерево классов может вообще быть эффективным, а?
Что-то как-то то, с чем я сталкивался, противоречит тому, что вы пишете.
> может ли java компилировать код в нативный
да, gcj, но его вообще нечасто используют, а уж для веба — почти никогда.
да, gcj, но его вообще нечасто используют, а уж для веба — почти никогда.
сборка мусора все усилия сведет на нет. в то время как на C (и в гамаке на C++) можно просто программировать на пулах и точно так же не заботиться об освобождении памяти.
Думаю, не стоит начинать тут холивар Java vs .NET :)
Обе технологии примерно одинаковы по своим преимуществам, но различаются в деталях — тут уже кому что больше нравится или каквы изначальные требования. Java более кроссплатформенна, однако у MS так или иначе — интеграция со своими другими технологиями (от Dynamics до Office Desktop) и средствами разработки.
Ну и много всего другого, не хочу здесь начинать это обсуждение.
Обе технологии примерно одинаковы по своим преимуществам, но различаются в деталях — тут уже кому что больше нравится или каквы изначальные требования. Java более кроссплатформенна, однако у MS так или иначе — интеграция со своими другими технологиями (от Dynamics до Office Desktop) и средствами разработки.
Ну и много всего другого, не хочу здесь начинать это обсуждение.
1000 хитов в секунду на java — вполне реальность, сам лично делал на 1 ядре (на целероне).
А если это будет HelloWorld и keep-alive соединения то и 10000 в секунду выдержит.
А если это будет HelloWorld и keep-alive соединения то и 10000 в секунду выдержит.
Ага. Главное — быть поосторожнее с памятью, а то java любит задумываться, когда gc просыпается :)
В принципе, производительность была постоянной.
Если скачки и были то в интервалах сильно меньше 1 секунды, потому что в любую из секунд сервер обрабатывал необходимые 1000 реквестов :)
А вообще самое медленное с чем я столкнулся — это выделение памяти под массивы (в частности массивы байтов), это прям съедало основное время, поэтому я сам распарсивал реквесты, все данные перегонял по запуленным массивам байтов, ну и конечно же nio, так как 1000 thread'ов тоже просто убивают jvm :)
Если интересно посмотреть мои поделки детства то оно вот тут sourceforge.net/projects/ixstrim/
Если скачки и были то в интервалах сильно меньше 1 секунды, потому что в любую из секунд сервер обрабатывал необходимые 1000 реквестов :)
А вообще самое медленное с чем я столкнулся — это выделение памяти под массивы (в частности массивы байтов), это прям съедало основное время, поэтому я сам распарсивал реквесты, все данные перегонял по запуленным массивам байтов, ну и конечно же nio, так как 1000 thread'ов тоже просто убивают jvm :)
Если интересно посмотреть мои поделки детства то оно вот тут sourceforge.net/projects/ixstrim/
Думаю, что тут просто многие под Java понимают использование какого-либо APP-сервера.
То, что C++, Java и C# при использовании схожей архитектуры будут показывать сравнимую производительность, по-моему очевидно.
То, что C++, Java и C# при использовании схожей архитектуры будут показывать сравнимую производительность, по-моему очевидно.
Про APP-сервера возможно Вы правы :)
Про сравнимую производительность при схожей архитектуры тоже правы :)
Перед тем как начать использовать java (это было в 1999 году), первое что я сделал — это проверил как отличается производительность Java vs Си на трех задачах:
1) qsort (разница была 5% в пользу Си)
2) передача данных по сети просто пинг сервер и клиент, разницы не было
3) операции с жестким диском (тестировались потоковое чтение и seek'и) разницы не было
На Си тесты писали матерые перцы, так что все было по честному :)
Про сравнимую производительность при схожей архитектуры тоже правы :)
Перед тем как начать использовать java (это было в 1999 году), первое что я сделал — это проверил как отличается производительность Java vs Си на трех задачах:
1) qsort (разница была 5% в пользу Си)
2) передача данных по сети просто пинг сервер и клиент, разницы не было
3) операции с жестким диском (тестировались потоковое чтение и seek'и) разницы не было
На Си тесты писали матерые перцы, так что все было по честному :)
Ну, у C# есть преимущества перед Java, поскольку язык чуть богаче выразительно — есть разные там лямбды, замыкания, LINQ. Впрочем, роли не играет — выбор здесь не Java vs. C#, а C++ vs Java/C#.
Я лично за Java и за кластер. C++, конечно, может дать скорость, но выигрыш будет не в 2-3 раза, а на 20-30%. Это максимум, потому что реально скорость будет практически один к одному за счёт JIT.
Решение на одном сервере имеет 2 недостатка: ненадёжно, немасштабируемо. Если требуется такая нагрузка, то нет гарантий, что через год она не возрастёт в 1,5-2 раза. И тогда единственный выход — менять железо.
В общем, больших преимуществ C++ перед Java здесь нет. Зато есть недостатки.
Я лично за Java и за кластер. C++, конечно, может дать скорость, но выигрыш будет не в 2-3 раза, а на 20-30%. Это максимум, потому что реально скорость будет практически один к одному за счёт JIT.
Решение на одном сервере имеет 2 недостатка: ненадёжно, немасштабируемо. Если требуется такая нагрузка, то нет гарантий, что через год она не возрастёт в 1,5-2 раза. И тогда единственный выход — менять железо.
В общем, больших преимуществ C++ перед Java здесь нет. Зато есть недостатки.
У вас несколько вариантов
1.Перенимайте опыт у google, многие процессы у них на python, и как уже писали ниже, некоторые можно точить на С++.
2.Используйте C#, он даст скорость в разработке, я думаю раза в два.
3.С++
4.Свои велосипеды.
1.Перенимайте опыт у google, многие процессы у них на python, и как уже писали ниже, некоторые можно точить на С++.
2.Используйте C#, он даст скорость в разработке, я думаю раза в два.
3.С++
4.Свои велосипеды.
1. Насколько я знаю в Google ничего держащего большую нагрузку не использует Python. Вот «обвязка» (системы мониторинга, отчёты, оффлайновая обработка данных) — это да.
2. Я очень сомневаюсь что C# даст сильно бо́льшую скорость чем Java. Он даст экономию на программистах, но тут вроде это не главное.
2. Я очень сомневаюсь что C# даст сильно бо́льшую скорость чем Java. Он даст экономию на программистах, но тут вроде это не главное.
Движок гугла был сделан на C++ и поставлен на линукс, дальнейшая судьба мегакластера неизвестна :)
НЛО прилетело и опубликовало эту надпись здесь
нам почти заказали сайт на Ассемблере. еле удалось убедить манагеров, что никто из разработчиков не знает asm.
эх, весёлое было времечко… (;
эх, весёлое было времечко… (;
То что скомпиленный рукописный асм-код будет быстрее скомпиленного современным компилятором рукописного кода на Си (++, etc) — распространенное заблуждение. При кодировании на асме сложного приложения руками надо учесть СТОЛЬКО факторов и столько всего в голове держать, столько всяких вещей просчитывать, что человеку это если и под силу, то ооооооочень медленно и с кучей (трудноуловимых) ошибок.
Это миф. Во-первых, чтобы Си (и тем более Си++)-программа была эффективной, тоже надо держать в голове кучу факторов, надо фактически писать как на асме, достаточно один раз использовать например STL — и сразу же вес программы подскочит, а производительность нет.
И почему интересно компилятор генерирует более эффективный код, чем человек? Что железка умнее?
И почему интересно компилятор генерирует более эффективный код, чем человек? Что железка умнее?
> Во-первых, чтобы Си (и тем более Си++)-программа была эффективной, тоже надо держать в голове кучу факторов,
Вот только при написании на Си не надо держать в голове тех вещей, которые надо деражть когда пишешь на голом асме. Многое берёт на себя компилятор.
> достаточно один раз использовать например STL — и сразу же вес программы подскочит, а производительность нет.
С удовольствием посмотрю, как вы воспользуетесь STL в C :). А если серьёзно, то STL-ем тоже надо уметь пользоваться.
Никто не говорит, что код на Си всегда более эффективен, естественно надо писать с умом. Но, соглситесь, гораздо проще возложить много рутинной и очень сложной работы по раскидыванию переменных по регистрам (переменных много, а регистров мало), по описанию всяких вызовов функций, по input/output (в том числе файловом) и т.п. на компилятор и озадачится написанием эффективного кода на более высоком уровне абстракции (всё таки Си это язык более выского уровня чем асм, хотя и не такого как, например, питон).
Попробуйте написать какое-нибудь более-менее нетривиальное приложение на Си (например, простой лексический анализатор) и на асме — поймёте о чем я говорю.
Вот только при написании на Си не надо держать в голове тех вещей, которые надо деражть когда пишешь на голом асме. Многое берёт на себя компилятор.
> достаточно один раз использовать например STL — и сразу же вес программы подскочит, а производительность нет.
С удовольствием посмотрю, как вы воспользуетесь STL в C :). А если серьёзно, то STL-ем тоже надо уметь пользоваться.
Никто не говорит, что код на Си всегда более эффективен, естественно надо писать с умом. Но, соглситесь, гораздо проще возложить много рутинной и очень сложной работы по раскидыванию переменных по регистрам (переменных много, а регистров мало), по описанию всяких вызовов функций, по input/output (в том числе файловом) и т.п. на компилятор и озадачится написанием эффективного кода на более высоком уровне абстракции (всё таки Си это язык более выского уровня чем асм, хотя и не такого как, например, питон).
Попробуйте написать какое-нибудь более-менее нетривиальное приложение на Си (например, простой лексический анализатор) и на асме — поймёте о чем я говорю.
Компилятор может генерировать более эффективный код именно потому, что он железка, и ему всё равно, какого размера получится код функцийй — 200 инструкций или 2000 инструкций.
Конечно железяка не сравнится с человеком, но чтобы написать код более эффективно, чем это делает компилятор, требуется потратить много усилий. Человек может позволить себе это для нескольких мест в программе, но на то чтобы сделать это со всей программой просто не хватит времени и сил, а код в результате получится неподдерживаемым.
Примеры банальны: Как часто вы на ассемблере делаете:
1) Открытую подстановку (инлайн), вместе с протяжкой констант, удалением неиспользуемого кода и вычислением константных выражений и после этого ещё и новым перераспределением регистров? Как обстоят дела с поддержкой такого кода?
2) Часто ли вы делаете раскрутку циклов более сложных, чем пара инструкций (например инструкций 15)?
Конечно железяка не сравнится с человеком, но чтобы написать код более эффективно, чем это делает компилятор, требуется потратить много усилий. Человек может позволить себе это для нескольких мест в программе, но на то чтобы сделать это со всей программой просто не хватит времени и сил, а код в результате получится неподдерживаемым.
Примеры банальны: Как часто вы на ассемблере делаете:
1) Открытую подстановку (инлайн), вместе с протяжкой констант, удалением неиспользуемого кода и вычислением константных выражений и после этого ещё и новым перераспределением регистров? Как обстоят дела с поддержкой такого кода?
2) Часто ли вы делаете раскрутку циклов более сложных, чем пара инструкций (например инструкций 15)?
забавно будет увидеть вэбфрамеворк на ассемеблере))
highscalability.com/
Там есть примеры и LAMP-систем. Например, Digg…
Там есть примеры и LAMP-систем. Например, Digg…
еще могу посоветовать: www.insight-it.ru
Есть цикл статей про архитектуру высоконагруженных сервисов: flickr, google, youtube, ЖЖ, wikimedia и т.д.
Есть цикл статей про архитектуру высоконагруженных сервисов: flickr, google, youtube, ЖЖ, wikimedia и т.д.
Веб приложение же вроде генерит HTML, а не парсит?
А если парсить надо, то я делал самописный HTML парсер по подобию SAX, дак он на одном ядре 3000Мгц 70Мб/сек парсил, и оптимизировать еще было куда.
Это я про java говорю.
А если парсить надо, то я делал самописный HTML парсер по подобию SAX, дак он на одном ядре 3000Мгц 70Мб/сек парсил, и оптимизировать еще было куда.
Это я про java говорю.
Стоимость работы cpp программистов дороже стоимости дополнительного железа.
Скорость разработки на cpp намного ниже, чем у простых интерпретируемых языков.
Да и вообще, критичные к производительности модули и так делаются на c.
Если вдруг вам самим потребовалось что-то сделать быстрым, то проще изучить инструменты типа swig, которые позволяют преобразовать код на питоне, например, в код на c и собрать бинарный модуль под конкретную небольшую задачу, оставив управляющий код тому же питону.
Скорость разработки на cpp намного ниже, чем у простых интерпретируемых языков.
Да и вообще, критичные к производительности модули и так делаются на c.
Если вдруг вам самим потребовалось что-то сделать быстрым, то проще изучить инструменты типа swig, которые позволяют преобразовать код на питоне, например, в код на c и собрать бинарный модуль под конкретную небольшую задачу, оставив управляющий код тому же питону.
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 миллионов хитов на сервер в сутки.
При таком количестве запросов спасает не только язык, но и руки того, кто делает задачу.
Держал до 40 миллионов хитов в сутки. Тормозить начал, когда трафик приблизился к 60 миллионам в сутки.
Выполняемая функция — хостинг баннерообменных сеток на своем движке.
2. Статистика Liveinternet.ru:
roem.ru/2009/01/26/addednews9350/?c#message31540
4 сервера во фронтенде. Суточный трафик — порядка 2 миллиардов (с хвостиком) хитов — www.liveinternet.ru/stat/ru/
Получаем в среднем от 500 миллионов хитов на сервер в сутки.
При таком количестве запросов спасает не только язык, но и руки того, кто делает задачу.
Я думаю что такие масштабы надо как-то и проектировать и писать по другому.
Я где-то читал что вот в Yaндексе сначала пишут тестовый вариант на Python. Это быстро и удобно.
Потом это все переводится на C (С++). Добиваются максимальной производительности.
Я где-то читал что вот в Yaндексе сначала пишут тестовый вариант на Python. Это быстро и удобно.
Потом это все переводится на C (С++). Добиваются максимальной производительности.
Безусловно, писаться будет изначально по другому. 10 SQL запросов на страницу не будет.
В идеале — 1 SQL запрос на 10 хитов, остальное в памяти :-)
насчет Python — уверен, прототип можно писать на любом из современных языков веб разработки (PHP/Perl/Ruby — кому что удобнее, мне PHP например).
В идеале — 1 SQL запрос на 10 хитов, остальное в памяти :-)
насчет Python — уверен, прототип можно писать на любом из современных языков веб разработки (PHP/Perl/Ruby — кому что удобнее, мне PHP например).
Идеалогия Python осень сильно отличается от PHP, и очень подходит именно для написания веб-приложения. Если вспомнить, что оптимизировать нужно в своё время, то Python, с его возможностью написания модулей на C — просто конфетка.
писать extention для PHP религия не позволяет?
Лично я не пробовал писать модули для Python на Си, но зато пробовал extension для PHP — камасутра ещё та.
Zend Engine 2 вышел уже бог знает сколько лет назад (вместе с PHP 5), а по нему до сих пор нет толковой официальной документации!
Пришлось лезть в сорцы расширений из PECL'а и расшифровывать их.
При всей моей любви к PHP, в этом плане он меня сильно разочаровал :(
Кстати, возможно документация/туториалы есть, но я их не нашел — тогда буду благодарен за ссылку. Желательно с нормальными примерами использования объектов, а то я находил сплошные костыли типа ZEND_NAMED_FE.
Zend Engine 2 вышел уже бог знает сколько лет назад (вместе с PHP 5), а по нему до сих пор нет толковой официальной документации!
Пришлось лезть в сорцы расширений из PECL'а и расшифровывать их.
При всей моей любви к PHP, в этом плане он меня сильно разочаровал :(
Кстати, возможно документация/туториалы есть, но я их не нашел — тогда буду благодарен за ссылку. Желательно с нормальными примерами использования объектов, а то я находил сплошные костыли типа ZEND_NAMED_FE.
Ммм… Что является аналогом Cython для PHP, не напомните?
на прошлой работе делали один очень похожий архитектурно проект
написали на Си, sql нет вообще — все в бинарных самописных бд, оператиыные данные — в памяти
http обрабатывается lighttpd+fastcgi
ожидаемая нагрузка — по 1 млн динамических хитов на ноду (всего 3 ноды)
писал один человек в течении примерно 3 месяцев
написали на Си, sql нет вообще — все в бинарных самописных бд, оператиыные данные — в памяти
http обрабатывается lighttpd+fastcgi
ожидаемая нагрузка — по 1 млн динамических хитов на ноду (всего 3 ноды)
писал один человек в течении примерно 3 месяцев
В яндексе Не пишут сначала тестовый вариант на питон. В яндексе много проектов. Одни на одном, другие — на другом. Мой круг вот вообще на PHP написан. Но это не повод говорить, что в Яндексе пишут приложения на PHP.
Взяли питонового человека — стали писать «сначала» тестовый вариант на питоне. То, что его в итоге перепишут на C/C++ это еще не факт.
По большому счету, вообще все равно на чем писать бекенд, так как 20000000 хитов в сутки разделить на 86400 — это получается всего-навсего 231. Даже если считать, что у нас в сутках 10 часов (часы пик и тп) — то это 500 RPS.
500 RPS с сервера достигается на чем угодно, если руки растут из плеч, даже на PHP, не к ночи будь помянут.
Взяли питонового человека — стали писать «сначала» тестовый вариант на питоне. То, что его в итоге перепишут на C/C++ это еще не факт.
По большому счету, вообще все равно на чем писать бекенд, так как 20000000 хитов в сутки разделить на 86400 — это получается всего-навсего 231. Даже если считать, что у нас в сутках 10 часов (часы пик и тп) — то это 500 RPS.
500 RPS с сервера достигается на чем угодно, если руки растут из плеч, даже на PHP, не к ночи будь помянут.
Ну мойкруг они не писали, а купили… С командой, а вообще насколько мне известно ПХП в яндексе очень мало.
Да, все так. Да, на php мало, потому что в здравом уме на нем врядли кто писать будет, так как язык мерзкий, а технической стороной в яндексе заправляют технические специалисты. Но количество проектов на питоне там немногим превышает количество проектов на PHP, с одной стороны, а с другой — при наличии инфраструктуры и отлаженных средств управления ей — уже все равно на чем писать бекенды. Есть проекты на перле, например. Никто же не говорит, что «яндекс написан на перле».
я вообще ничего не говорю :). Но не надо холивара насчёт мерзости языка. Я умоляю вас. Если ума не хватает как заставить нормально работать, это еще не причина кричать, что язык мерзкий.
Насчет ума — спасибо, повеселили. Наверное, PHP это для исключительно умных людей. Интересно, на чем разрабатывают веб-приложения все остальные.
нет разницы на чем писать — главное иметь голову на плечах. И уже и примеры приводили и все остальное — нет же люди утверждают что всё равно. Ну… продолжайте. Мне вот разницы нет на чём писать — хоть ПХП, хоть Руби, хоть Перл, почти хоть питон, уже почти почти хоть ерланг. Просто не обижайте мой первый коммерческий язык программирования. Очень обидно слышать.
Разница между языками есть. В трудоемкости разработки. В выразительности. В количестве в дефектов (статическая типизация — меньше, динамическая — больше). В производительности (таки да). В наличии и количестве необходимых библиотек. В качестве этих библиотек. В легкости разрабатывать масштабируемые решения. В стоимости и наличии необходимых специалистов для разработки и поддержки.
Если бы разницы не было — то все бы так и писали на С, и всех бы все устраивало.
Обидеть язык программирования невозможно, он не человек. А уж если человек действительно пишет на многих языках, то врядли его может задеть упоминание, что какой-то язык — так себе язык. Тем более, что если человек на всех этих языках пишет, то не может не видеть, что они ВСЕ — так себе, в том или ином. Ну, правда есть языки от которых пованивает, но замечаешь это не сразу, а есть такие, от которых просто смердит.
Если бы разницы не было — то все бы так и писали на С, и всех бы все устраивало.
Обидеть язык программирования невозможно, он не человек. А уж если человек действительно пишет на многих языках, то врядли его может задеть упоминание, что какой-то язык — так себе язык. Тем более, что если человек на всех этих языках пишет, то не может не видеть, что они ВСЕ — так себе, в том или ином. Ну, правда есть языки от которых пованивает, но замечаешь это не сразу, а есть такие, от которых просто смердит.
Еще раз доношу до вас свою точку зрения — если уметь — то нет разницы на чем писать. Уже много раз приводились примеры фасебука и википедии, но все равно люди продолжают кричать — я бы никогда не выбрал пых и мускуль для высоконагруженных проектов. Да там много что не на пыхе и мускули там наполовину своими патчами прошити, но и любой другой язык из коробки не справился бы с такими нагрузками.
Я в самом первом сообщении написал, что «с другой — при наличии инфраструктуры и отлаженных средств управления ей — уже все равно на чем писать бекенды». Я не сомневаюсь, что на PHP можно написать нагруженный проект. Про MySQL я вообще ни слова не сказал — это вы с самим собой спорите, что ли?
Но языки, инструменты, все разные. На одних проще сделать качественный и расширяемый продукт, на других это менее просто.
И на последок таки донесу свою точку зрения — разница на чем писать есть. И разница в результате в зависимости от выбора инструментария — тоже есть. И от умения это, зачастую, никак не зависит, если, конечно, вы в необходимые умения не зачисляете исправление и переписывание выбранной платформы.
Но языки, инструменты, все разные. На одних проще сделать качественный и расширяемый продукт, на других это менее просто.
И на последок таки донесу свою точку зрения — разница на чем писать есть. И разница в результате в зависимости от выбора инструментария — тоже есть. И от умения это, зачастую, никак не зависит, если, конечно, вы в необходимые умения не зачисляете исправление и переписывание выбранной платформы.
Digg — «написан» на LAMP-е
>Но языки, инструменты, все разные. На одних проще сделать качественный и расширяемый продукт, на других это менее просто.
Понятия «просто», «проще» и т.п. вы как оцениваете? Трудозатраты (человеко-часы) или еще как? Если трудозатраты, то оцениваете ли разницу в стоимости человеко-часа для разных языков, на какую квалификацию ориентируетесь?
>И на последок таки донесу свою точку зрения — разница на чем писать есть. И разница в результате в зависимости от выбора инструментария — тоже есть.
Конечно есть, и зачастую язык, «от которого смердит», является оптимальным выбором для достижения необходимого результата ;) Не смотря на выразительность, красоту и элегантность других языков, а зачастую и не смотря на их производительность и т. п. Главное какой результат нужен, и выбор среди каких средств для его достижения есть в рамках бюджета/срока
Понятия «просто», «проще» и т.п. вы как оцениваете? Трудозатраты (человеко-часы) или еще как? Если трудозатраты, то оцениваете ли разницу в стоимости человеко-часа для разных языков, на какую квалификацию ориентируетесь?
>И на последок таки донесу свою точку зрения — разница на чем писать есть. И разница в результате в зависимости от выбора инструментария — тоже есть.
Конечно есть, и зачастую язык, «от которого смердит», является оптимальным выбором для достижения необходимого результата ;) Не смотря на выразительность, красоту и элегантность других языков, а зачастую и не смотря на их производительность и т. п. Главное какой результат нужен, и выбор среди каких средств для его достижения есть в рамках бюджета/срока
Приложения сразу надо писать для работы на нескольких серверах одновременно типа map reduce, тогда быстрее будет, особенно если задача сложная.
apache исключаем сразу.
+10 за nginx
+10 за nginx
чего это вдруг?
слишком тяжел для таких нагрузок он
У нас апач и соотв. модуль для него сейчас до 8000 запросов\сек отдаёт. Что я делаю не так?
ну апач это скорее вездеход с тремя наборами разных видов колес и системой динамического регулирования давления в них. а также с убирающимся верхом, несколькими багажниками, отстегивающимися подкрылками, четырьмя видами спойлеров (в базовой комплектации), кучей фар, кенгурятником, лебедкой и др. и пр.
nginx же — _просто_ _спортивный_ _автомобиль_. без излишеств. даже местами непокрашенный, да и фар почти нет. чисто заточен под свою основную функцию.
nginx же — _просто_ _спортивный_ _автомобиль_. без излишеств. даже местами непокрашенный, да и фар почти нет. чисто заточен под свою основную функцию.
НЛО прилетело и опубликовало эту надпись здесь
windows и не планируется.
Насчет C/C++ — разница в скорости с современными компиляторами(Intel C++) невелика, а вот программы надежнее (с STL, exceptions, Boost/Poco — меньше места для ошибки)
Насчет C/C++ — разница в скорости с современными компиляторами(Intel C++) невелика, а вот программы надежнее (с STL, exceptions, Boost/Poco — меньше места для ошибки)
НЛО прилетело и опубликовало эту надпись здесь
Высоконагруженность бывает разная :-)
Мне кажеться биллинг Masterhost-а это десятки тысяч хитов в день, а не миллионы.
Участвовал давно я на одном Java-проекте, где 4-х процессорный сервер загибался от 10-и пользователей, лазящих по форуму.
Но это конечно неэффективная реализация.
Мне кажеться биллинг Masterhost-а это десятки тысяч хитов в день, а не миллионы.
Участвовал давно я на одном Java-проекте, где 4-х процессорный сервер загибался от 10-и пользователей, лазящих по форуму.
Но это конечно неэффективная реализация.
«Реальность еще страшнее» (с), биллинг, пусть даже Мастерхоста — далеко не такой хайлоад, как кажется со стороны.
Сколько у .m клиентов? Доменов .ru — 88000. Возьмем за число клиентов — 200000. Кругло. С запасом.
Допустим, что каждому клиенту нужно попасть в _биллинг_ — 2 раза в неделю. Итого — 8 раз в месяц. Опять-же, округлим до 10 раз. Получаем 2000000 заходов в биллинг в месяц, 500000 в неделю, 71000 в день, 3000 в час, 50 в минуту и меньше 1 юзера в секунду.
Это много? Нет, это очень мало :)
Даже если этих самых юзеров в минуту будет не 50, а 500, да даже 1000. Это все равно очень далеко до объемов не то, что гугла, а даже хабра.
Естественно, все рассчеты — очень примерные и врятли имеют отношение к реальности. Просто биллинг — сугубо техническая вещь, которая нужна клиентам не так часто. Я бы сказал совсем не часто. Чего там делать-то каждые 15 минут? Я думаю, 80% клиентов вообще заходят туда раз в месяц, оплатить хостинг на следующий месяц. Все.
А вот нагрузки тикетницы или главной сайта .m уже куда интереснее :)
Сколько у .m клиентов? Доменов .ru — 88000. Возьмем за число клиентов — 200000. Кругло. С запасом.
Допустим, что каждому клиенту нужно попасть в _биллинг_ — 2 раза в неделю. Итого — 8 раз в месяц. Опять-же, округлим до 10 раз. Получаем 2000000 заходов в биллинг в месяц, 500000 в неделю, 71000 в день, 3000 в час, 50 в минуту и меньше 1 юзера в секунду.
Это много? Нет, это очень мало :)
Даже если этих самых юзеров в минуту будет не 50, а 500, да даже 1000. Это все равно очень далеко до объемов не то, что гугла, а даже хабра.
Естественно, все рассчеты — очень примерные и врятли имеют отношение к реальности. Просто биллинг — сугубо техническая вещь, которая нужна клиентам не так часто. Я бы сказал совсем не часто. Чего там делать-то каждые 15 минут? Я думаю, 80% клиентов вообще заходят туда раз в месяц, оплатить хостинг на следующий месяц. Все.
А вот нагрузки тикетницы или главной сайта .m уже куда интереснее :)
Это, что за форум (движок) такой был? Самопал?
НЛО прилетело и опубликовало эту надпись здесь
а может стоит обратить внимание на эрланг?
Он же страшно тормозной, вроде?
Именно поэтому его использовали для создания одной из частей чата facebook :)
Ok, посмотрел. Я ошибался. Он действительно заметно быстрее обычных скриптовых языков типа питона, перла и руби, но до джавы и c++ ему всё-таки далеко. Если уж говорить о функциональных языках (которым эрланг, насколько мне известно, является), то лучше уж выбрать хаскелл.
Я бы не сказал, что Эрланг быстрее кого-то в принципе. Он быстрее и надежнее в некотором классе задач. Хотя, наверное, для веба он быстрее на всех задачах из-за специфики веба. Кстати, там эти фэйсбучники еще и те самые плюсы (не к ночи будь помянуты) используют. Так что автору есть куда копать :)
ЗЫ. А почему именно хаскелл? Он для веба насколько актуален, в плане наличия фреймворков, инфраструктуры и т.п. Тот же самый разбор POST-запроса и прочее, биндинги к базам. Я с этой стороны просто на него никогда не смотрел.
ЗЫ. А почему именно хаскелл? Он для веба насколько актуален, в плане наличия фреймворков, инфраструктуры и т.п. Тот же самый разбор POST-запроса и прочее, биндинги к базам. Я с этой стороны просто на него никогда не смотрел.
В Гугле тоже значительная часть веб-сервисов на C++ написана.
Хаскелл — потому что с одной стороны достаточно быстр, а с другой стороны хорошо продуман (на код написанный на оКамле я смотреть без ужаса не могу). Вроде бы всё что нужно (библиотечки для веб, БД) для него есть, хотя подробно я этот вопрос не изучал…
Хаскелл — потому что с одной стороны достаточно быстр, а с другой стороны хорошо продуман (на код написанный на оКамле я смотреть без ужаса не могу). Вроде бы всё что нужно (библиотечки для веб, БД) для него есть, хотя подробно я этот вопрос не изучал…
Haskell для веба — HAppS. С привязкой к БД тоже вроде всё нормально. На высокопроизводительный сервер на Haskell будет интересно посмотреть (без иронии).
В любом случае, что Erlang, что Haskell для таких задач надо уметь готовить — чуда не случится.
В любом случае, что Erlang, что Haskell для таких задач надо уметь готовить — чуда не случится.
Эрланг в отличии от Хаскеля заточен исключительно под многопоточность, за счет этого и происходит выигрыш при больших нагрузках.
www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-1/
там три части истории, рекомендую прочесть
не совсем о скорости но все равно интересно
там три части истории, рекомендую прочесть
не совсем о скорости но все равно интересно
Вам надо перестать думать о языке реализации и сразу подумать о масштабировании всего вашего хозяйства. Если это веб-проект то со временем нагрузки будут только расти, и вы очень быстро перейдёте грань, где преимущества в скорости С++ (пусть и в несколько раз) на интерпретируемыми языками уже не будут ничего решать. А сложностей разработки и масштабирования приложений на С++ больше. Да и почему php обязательно? Можно выбрать ruby или python, или даже эрланг(тем более с его возможностями по масштабированию). К тому же непонятно, какой характер носит приложение. Если оно делает какие-то тяжёлые вычисления, тогда имеет смысл думать о их реализации на С++ в виде процесса демона на бэкенде. А отдавать и генерировать фронтенд на С++ не стоящая свеч идея.
PHP просто потому что у меня с ним опыта больше, чем с Ruby/Python. При правильной настройке эти языки показывают схожую производительность.
Приложение — обычный сайт, никаких вычислений.
Да, безусловно грань есть, на мой взгляд на уровне порядка 15-30кк хитов в день.
Однако не могу сказать что масштабирование C++ сложнее того же PHP. Поставить 5 серверов за reverse proxy — так же просто.
Одно дело ставить прокси допустим только через 2 года, а другое — начинать добавлять серверы по 1 шт в месяц уже через пол года.
Приложение — обычный сайт, никаких вычислений.
Да, безусловно грань есть, на мой взгляд на уровне порядка 15-30кк хитов в день.
Однако не могу сказать что масштабирование C++ сложнее того же PHP. Поставить 5 серверов за reverse proxy — так же просто.
Одно дело ставить прокси допустим только через 2 года, а другое — начинать добавлять серверы по 1 шт в месяц уже через пол года.
Ну да, производительность то схожая, но писать на тех же рельсах поприятнее. :)
Я просто к тому, что если всё так обычно, то зачем изобретать велосипед. Если бы использование С++ экономически оправдывалось мы бы в вебе чаще о нём слышали :). Тем более, скорее всего узким местом будет, как всегда, база данных.
Я просто к тому, что если всё так обычно, то зачем изобретать велосипед. Если бы использование С++ экономически оправдывалось мы бы в вебе чаще о нём слышали :). Тем более, скорее всего узким местом будет, как всегда, база данных.
Кому на чем удобнее, тот на том и пишет )
Так в этом и идея, что база только для долговременного хранения и редких сложных запросов.
Все простое — внутри моментально получается из памяти.
Так в этом и идея, что база только для долговременного хранения и редких сложных запросов.
Все простое — внутри моментально получается из памяти.
C++ модули используется во всех нагруженных продуктах (Amazon, Facebook, Google, etc). Другое дело что мало где всё пишут на C++.
С добавлением серверов тоже не все так просто. Можно зарытся в SQL, причем не в сравнительно легко масштабируемый SELECT, а именно в инсерты, гораздо раньше чем понадобится второй сервер под фронтенд.
Все зависит от специфики сайта.
Все зависит от специфики сайта.
есть опыт с ПХП и 2.5м хит в день. 2 веб сервера, 1 БД сервер
у вас проект сразу до такой нагрузки прыгнет? думаю пробемы можно решать по мере поступление.
и просто например покупать еще один сервер, который обойдется дешевле чем разработчик на С++
у вас проект сразу до такой нагрузки прыгнет? думаю пробемы можно решать по мере поступление.
и просто например покупать еще один сервер, который обойдется дешевле чем разработчик на С++
думаю затраты на c++ не оправдают себя
Если обычная вебапликуха — подойдет и php. Если что то более серьезное — я бы смотрел в сторону java (по сравнению с с++ надежность будет значительно выше, разработка дешевле, сапорт проще). Ну и в любом случае изначально рассчитывать на кучу серверов.
Да и с .net есть конкретный опыт, когда система под нагрузочными тестами вполне выдерживала подобную нагрузку.
Если обычная вебапликуха — подойдет и php. Если что то более серьезное — я бы смотрел в сторону java (по сравнению с с++ надежность будет значительно выше, разработка дешевле, сапорт проще). Ну и в любом случае изначально рассчитывать на кучу серверов.
Да и с .net есть конкретный опыт, когда система под нагрузочными тестами вполне выдерживала подобную нагрузку.
board.rt.mipt.ru/ на плюсах написано
а по поводу производительности — грамотное кэширование и прокси-сервера и так спасают. Логика-то не сильно нагружает проц, больше база.
а по поводу производительности — грамотное кэширование и прокси-сервера и так спасают. Логика-то не сильно нагружает проц, больше база.
Да, именно по этому я не планирую даже memcached, а кешировать внутри C++ приложения с минимальной нагрузкой на БД.
А по поводу форума — Requests per second: 22.06 [#/sec] при 100 запросах параллельно, куда-то там у них упирается.
А по поводу форума — Requests per second: 22.06 [#/sec] при 100 запросах параллельно, куда-то там у них упирается.
я просто к тому, что на там же железе можно было поднять более производительное приложение. А на чем уже поднимать — тут не критично, поэтому я бы сконцентрировался на надежности и масштабируемости.
Далеко не факт, что вам получится сделать быстрее, чем memcached. В конце концов, это серьезная разработка, в нем немало алгоритмов оптимизации. Зачем велосипедить?
А на чем еще можно писать такое? :) Разве что на асме :)
Да вы, батенька, мазохист!
Без обид, но уж больно долго вы будете ЭТО создавать.
Без обид, но уж больно долго вы будете ЭТО создавать.
собственный опыт
два сервера ксеоны по 4 гига памяти и база на третьем
nginx+fast-cgi+php+mysql
без мемкеша держали нагрузку в 7.5к запросов в секунду… и ничего… масштабировалось это дело просто подкидыванием еще одного сервера под fast-cgi и все :)
не самое лучшее решение, однако нам хватило
два сервера ксеоны по 4 гига памяти и база на третьем
nginx+fast-cgi+php+mysql
без мемкеша держали нагрузку в 7.5к запросов в секунду… и ничего… масштабировалось это дело просто подкидыванием еще одного сервера под fast-cgi и все :)
не самое лучшее решение, однако нам хватило
А opcode cache?
Это со статикой 7.5к или только к PHP?
Это со статикой 7.5к или только к PHP?
специфика приложения такова что статики нет вообще — только динамика- при каждом запросе 5-6 запросов в базу для выяснения данных и тп…
opcode cache — никакого :) не было нужды ставить просто… держат и хорошо (не верный подход, но не буду это обсуждать тут)
хотя потом на другом проекте практически такой же нагрузки был поставлен eAccelerator, что снизило нагрузку практически в 1.5 раза
opcode cache — никакого :) не было нужды ставить просто… держат и хорошо (не верный подход, но не буду это обсуждать тут)
хотя потом на другом проекте практически такой же нагрузки был поставлен eAccelerator, что снизило нагрузку практически в 1.5 раза
НЛО прилетело и опубликовало эту надпись здесь
Каждая версия скриптов выкладывается в отдельную папку на всех машинах, вебсервер смотрит в папку /default/, которая линкуется на текущую версию. При написании новой версии нужно тольок синхронно обносить симлинки на всех машинах, например с помощью cexec, работает не в пример быстрее чем обновление кеша NFS.
а мы сделали еще проще…
есть тестовый сервер где обкатываются скрипты — как только дается добро на установку на продакшн скрипты выкладываются на один «главный» условно сервер — остальные растаскивают по rsync
есть тестовый сервер где обкатываются скрипты — как только дается добро на установку на продакшн скрипты выкладываются на один «главный» условно сервер — остальные растаскивают по rsync
А сколько ядер на каждом ксеоне? По одному?
>Имел ли кто-либо из читателей опыт разработки веб-приложений на С++?
эээ… www.insight-it.ru/?
линкедин, например, 1000 (а то и поболее в моменты макс. загрузки — 40 миллионов просмотров страниц в день) в секунду держит. Практически всё Java.
зы вы вроде бы не назвали ни одной особой причины(=сложной задачи) по которой стоило бы предпочесть именно плюсы, а не java
эээ… www.insight-it.ru/?
линкедин, например, 1000 (а то и поболее в моменты макс. загрузки — 40 миллионов просмотров страниц в день) в секунду держит. Практически всё Java.
зы вы вроде бы не назвали ни одной особой причины(=сложной задачи) по которой стоило бы предпочесть именно плюсы, а не java
Кто-то на Хабре писал, что в Youtube самые критические места написаны или на c++ или вообще на asm, правда ли — не знаю :)
НЛО прилетело и опубликовало эту надпись здесь
А в чем проблема? Цель поста достигается, в комментах — полезные цифры по производительности конкретных систем, которые склоняют меня к варианту PHP+APC.
на счет акселератора я бы попробовал разные варианты и сравнил цифры для себя самого…
кстати если будете юзать мускл — юзайте innodb предварительно настроив его правильно — адская машина если дать ей 32 гигабайта памяти :)
кстати если будете юзать мускл — юзайте innodb предварительно настроив его правильно — адская машина если дать ей 32 гигабайта памяти :)
APC выбран не только из-за кеширования опкода, он еще и данные кэширует намного быстрее memcached по тестам.
да? а дайте линк на эти тесты…
хочу видеть как APC позволяет делать выборку по ключу из любого размера кеша за статическое время
может и себе заюзаю его…
хочу видеть как APC позволяет делать выборку по ключу из любого размера кеша за статическое время
может и себе заюзаю его…
www.mysqlperformanceblog.com/2006/08/09/cache-performance-comparison/
98k vs 12k
Ограничение понятно — apc не разносится по кластеру, а memcached — разносится.
98k vs 12k
Ограничение понятно — apc не разносится по кластеру, а memcached — разносится.
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.
так что все зависит от архитектуры вашего приложения…
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.
так что все зависит от архитектуры вашего приложения…
По опыту — я бы задумался о PHP+xCache+MemCached
1) xCache — несколько быстрее нежели eA
2) eA — существенно быстрее APC
3) ни один из них не вытягивает нормально множество чтений из памяти
4) изначально расчитывать на н-дцать серверов бекенда + ка-цать серверов Memcached + эль-цать серверов MySQL.
Я ведь верно понимаю, что первоочередная задача — минимизация времени простоя?
П.С. memcached не кеширует opcode, ага ;)
1) xCache — несколько быстрее нежели eA
2) eA — существенно быстрее APC
3) ни один из них не вытягивает нормально множество чтений из памяти
4) изначально расчитывать на н-дцать серверов бекенда + ка-цать серверов Memcached + эль-цать серверов MySQL.
Я ведь верно понимаю, что первоочередная задача — минимизация времени простоя?
П.С. memcached не кеширует opcode, ага ;)
НЛО прилетело и опубликовало эту надпись здесь
1) Железо — сколько нужно будет :-)
Заказчик изначально планировал 10к$ в месяц на железо, но имхо это перебор :-)
2) Затраты на разработку — это неизвестная переменная :-) В данном случае, это не самое главное.
3) тут реальное веб-приложение, допустим типа хабра, явно не пустая страничка.
Заказчик изначально планировал 10к$ в месяц на железо, но имхо это перебор :-)
2) Затраты на разработку — это неизвестная переменная :-) В данном случае, это не самое главное.
3) тут реальное веб-приложение, допустим типа хабра, явно не пустая страничка.
НЛО прилетело и опубликовало эту надпись здесь
1. Это не гиблая, а светлая идея :-) Один сервер намного эффективнее, чем куча серверов с синхронизацией.
2. Там писалось, что потратить в 3 раза времени чтобы реализовать на С++ — не проблема.
2. Там писалось, что потратить в 3 раза времени чтобы реализовать на С++ — не проблема.
НЛО прилетело и опубликовало эту надпись здесь
а) может и не наступить никогда, а если и наступит — nginx в виде прокси спасет (если приложение хоть чуть-чуть готово к этому) )
б) согласен
б) согласен
> а) он таки кончится, а приложение (surprise!!) не
> масштабируемое, потому что «лучше один большой
> сервер с C++, чем много маленьких с perl/ruby/erlang»
Производительности какого из компонентов железа по-Вашему может не хватить?
Каким образом вы предлагаете производить обмен данными между «маленькими серверами с „perl/ruby/erlang“?
Через базу? Тогда как вы гарантируете, что „не кончится“ сервер под базу? Масштабирование с помощью Partitioning/replication? Использовать memcached? Как решать проблему актуальности кэша при изменении данных в базе?
Если не через базу, то как вы будете осуществлять обмен данными между серверами? Как обеспечить синхронизацию одновременно между несколькими серерами?
Понимаете, всё зависит от типа задачи. Если у вас „сайт вроде Хабра“, где запросов на чтение сильно больше запросов на запись, и нет интерактивности в реальном времени, то возможно большинство из прелестей синхронизации вам удастся избежать. Если же вам требуется болше интерактивности, то это может стать серьёзной проблемой. Представьте себе банальный чат на нескольких серверах без использования базы.
Вот и делается попытка избежать всех этих прелестей, попытавшись уместить всё в одном срервере. Гораздо проще масштабировать по количеству ядер/объёму памяти, чем по количеству серверов.
> масштабируемое, потому что «лучше один большой
> сервер с C++, чем много маленьких с perl/ruby/erlang»
Производительности какого из компонентов железа по-Вашему может не хватить?
Каким образом вы предлагаете производить обмен данными между «маленькими серверами с „perl/ruby/erlang“?
Через базу? Тогда как вы гарантируете, что „не кончится“ сервер под базу? Масштабирование с помощью Partitioning/replication? Использовать memcached? Как решать проблему актуальности кэша при изменении данных в базе?
Если не через базу, то как вы будете осуществлять обмен данными между серверами? Как обеспечить синхронизацию одновременно между несколькими серерами?
Понимаете, всё зависит от типа задачи. Если у вас „сайт вроде Хабра“, где запросов на чтение сильно больше запросов на запись, и нет интерактивности в реальном времени, то возможно большинство из прелестей синхронизации вам удастся избежать. Если же вам требуется болше интерактивности, то это может стать серьёзной проблемой. Представьте себе банальный чат на нескольких серверах без использования базы.
Вот и делается попытка избежать всех этих прелестей, попытавшись уместить всё в одном срервере. Гораздо проще масштабировать по количеству ядер/объёму памяти, чем по количеству серверов.
Можно посмотреть в сторону OCaml-а/Ocsigen, который не сильно проигрывает в производительности Сям (будучи откомпилённым). Но параллелится будет легче, ФП всё-таки.
Специфические функциональные способности к распараллеливанию у OCaml нулевые — потоки в нём всегда захватывают глобальный мьютекс. А если использовать процессы, то свойства языка уже без разницы. Скорость линейного исполнения хорошая, да (и именно про это была статья на eigenclass, домысливать не надо ;-) ).
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
> Потому что когда по хитам в сутки вы дойдете до потолка возможностей
> вашего сервера, все равно придётся делать его масштабируемым.
> Поэтому лучше заложить это в архитектуру изначально.
Где, по Вашему мнению, будет узкое место (т. е. я понимаю что без знания точной специфики приложения, но хотя бы варианты)? Т. е. мощности какой части железа может не хватить?
> вашего сервера, все равно придётся делать его масштабируемым.
> Поэтому лучше заложить это в архитектуру изначально.
Где, по Вашему мнению, будет узкое место (т. е. я понимаю что без знания точной специфики приложения, но хотя бы варианты)? Т. е. мощности какой части железа может не хватить?
Я бы выбрал вариант с memcached. Оставляет больший зазор для масштабирования.
Все очень сильно зависит от задачи.
Может быть C++ действительно очень оправдан (а то и некий аппаратный блок!).
Но в общем случае, думаю, что затраты на содержание и поддержку (совокупная стоимость владения) в случае C++ сведут на нет все его преимущества. Я к тому, что лучше использовать специализированные технологии не только из за их технических параметров, но и иметь в виду организационные моменты. Поддерживать ресурс на C++, отслеживать баги и утечки памяти (а без них не получится в более-менее сложном проекте) намного дороже и дольше, чем использовать предназначенные для этого технологии.
Однако, в большом и сложном проекте вполне могут отдельные сервисы и низкоуровневые технологии использовать C++ (при том, что на других сделать то же самое невозможно или как минимум не проще).
P.S. И разумеется — архитектура, архитектура и еще раз архитектура.
P.P.S. Да, в определенных случаях, железо докупать действительно дешевле, чем поддерживать очень быструю и очень сложную систему. Плюс это повышает надежность (чем сложнее система, тем больше вероятность, что «что-нибудь где-нибудь да сломается»).
Может быть C++ действительно очень оправдан (а то и некий аппаратный блок!).
Но в общем случае, думаю, что затраты на содержание и поддержку (совокупная стоимость владения) в случае C++ сведут на нет все его преимущества. Я к тому, что лучше использовать специализированные технологии не только из за их технических параметров, но и иметь в виду организационные моменты. Поддерживать ресурс на C++, отслеживать баги и утечки памяти (а без них не получится в более-менее сложном проекте) намного дороже и дольше, чем использовать предназначенные для этого технологии.
Однако, в большом и сложном проекте вполне могут отдельные сервисы и низкоуровневые технологии использовать C++ (при том, что на других сделать то же самое невозможно или как минимум не проще).
P.S. И разумеется — архитектура, архитектура и еще раз архитектура.
P.P.S. Да, в определенных случаях, железо докупать действительно дешевле, чем поддерживать очень быструю и очень сложную систему. Плюс это повышает надежность (чем сложнее система, тем больше вероятность, что «что-нибудь где-нибудь да сломается»).
Писал на плюсах в 2000 году банерную систему. 3 миллиона показов в сутки — не вопрос. Apache, MySQL и 300MHz какой-то проц )
надо использовать кеширование + десяток серверов + распределение базы (разделение) + оптимизацию программного кода вне зависимости от серверного языка. поставьте изначально примерно такую задачу и тут такое начнётся по поводу приоритета языков, что мама не горюй )))
берёте ПЛИС, программируете её и делаете плату, которую вставляете в сервер. с нагрузкой справится 1 машина =)
Лавпланета так и написана, если не изменяет память.
Есть некоторый опыт разработки высокопроизводительных систем.
Считаю, что при отсутствии сложной вычислительной работы, т. е. если требуется только простая логика + операции с хранилищами данных (диск/БД) вы сможете добиться желаемой производительности даже на одном ядре класса Core 2.
Apache не годится, как и различные APP-сервера. Надо использовать предоставляемые системой средства для одновременной обработки большого количества запросов I/O (epool, kqueue, IOCP). Разница например между C# и C++ будет не очень велика, скорее будет отличаться потребление памяти, ну и возможно как-то могут сказаться паузы на GC. С Java немного сложнее (по крайней мере раньше так было, как сейчас точно сказать не могу, надо разбираться) в том смысле, что SE API не предоставляет эквивалента требуемым системным средствам.
Вообще язык реализации можно брать любой (с учётом ранее сказанных требований), естественно делая поправку на разницу примерной производительности с C/C++. Тут дело личных предпочтений (кому-то и на С++ может быть писать комфортнее и быстрее).
Преимущество подхода в том, что можно уместить всё на одной машине, а это очень хорошо, если запросы от разных пользователей (сессии) требуют обмена между собой информацией. Естественно надо готовиться, что железо будет стоить приличных денег (потребуется наращивать много памяти и возможно ядер, дисковый массив, если потребуется).
Может также возникнуть проблема с тем, что системе будет сложно одновременно работать с очень большим количеством соединений. В этом случае можно распределить их по «маленьким» прокси, которые будут просто сериализовать данные с нескольких соединений в одно и передавать их серверу.
Да, и подумайте ещё раз, перед тем как начинать разработку: точно ли у вас не будет узкого места с БД, потому что если будет, то все силы надо отправлять туда, а остальное уже вторично.
Считаю, что при отсутствии сложной вычислительной работы, т. е. если требуется только простая логика + операции с хранилищами данных (диск/БД) вы сможете добиться желаемой производительности даже на одном ядре класса Core 2.
Apache не годится, как и различные APP-сервера. Надо использовать предоставляемые системой средства для одновременной обработки большого количества запросов I/O (epool, kqueue, IOCP). Разница например между C# и C++ будет не очень велика, скорее будет отличаться потребление памяти, ну и возможно как-то могут сказаться паузы на GC. С Java немного сложнее (по крайней мере раньше так было, как сейчас точно сказать не могу, надо разбираться) в том смысле, что SE API не предоставляет эквивалента требуемым системным средствам.
Вообще язык реализации можно брать любой (с учётом ранее сказанных требований), естественно делая поправку на разницу примерной производительности с C/C++. Тут дело личных предпочтений (кому-то и на С++ может быть писать комфортнее и быстрее).
Преимущество подхода в том, что можно уместить всё на одной машине, а это очень хорошо, если запросы от разных пользователей (сессии) требуют обмена между собой информацией. Естественно надо готовиться, что железо будет стоить приличных денег (потребуется наращивать много памяти и возможно ядер, дисковый массив, если потребуется).
Может также возникнуть проблема с тем, что системе будет сложно одновременно работать с очень большим количеством соединений. В этом случае можно распределить их по «маленьким» прокси, которые будут просто сериализовать данные с нескольких соединений в одно и передавать их серверу.
Да, и подумайте ещё раз, перед тем как начинать разработку: точно ли у вас не будет узкого места с БД, потому что если будет, то все силы надо отправлять туда, а остальное уже вторично.
meshok.ru — php eAccelerator Mysql
250 — 400 запросов в секунду на динамике.
Все работает.
250 — 400 запросов в секунду на динамике.
Все работает.
Если я правильно понял, то вам можно связаться с Иваном Сагалаевым. Я восторгался его мужеством :) когда читал о том как он решал схожие проблемы на С++
Мне дали однажды тестовое задание написать за неделю с нуля вебсервер котороый будет отдавать как минимум 2000 запросов с данными с базы в секунду, на C. Я не понял что они шутили и сделал.
Им пришлось взять меня но потом через месяца три попросили уйти, на C они ничего на самом деле в конторе не писали. Это было до кризиса конечно.
Им пришлось взять меня но потом через месяца три попросили уйти, на C они ничего на самом деле в конторе не писали. Это было до кризиса конечно.
Лучше писать на Эрланге — на нормальном железе и прямых руках программиста способен держать миллион TCP соединений, мой товарищ когда про это рассказывал аж слюнями истек от восторга. Плюс, будучи функциональным он отлично масштабируется.
Как-то так:
1. Архитектура, должна быть приспособлена к горизонтальному масштабированию, что бы можно было поставить +1 сервер, развернуть там еще один бекенд и вперед, т.к. вертикальное масштабирование имеет разумные пределы.
2. В качестве фронтенда лучше использовать ngnix он довольно шустро умеет отдавать статику и не плохо справляется с fcgi проксированием.
3. Модули на c\c++ приятней писать под apache, много документации, большое комьюнити, куча примеров и много почти готовых решений, код которых можно использовать для своего велосипеда.
5. Лучше использовать fastcgi, он быстрей.
6. У fastcgi — есть один нездоровый косяк, по мнению многих, до тех пор пока бекенд на другом конце пайпа не отдаст вам данные, все запросы попадают в очередь и ждут смиренно пока не будет удачного ответа или же вылета по таймауту.
7. Для того, что бы fastcgi выдавал вам максимальные возможности, ваше приложение лучше сделать атомарным, запустить несколько процессов и забить их блоком в тот же ngnix для проксирования.
1. Архитектура, должна быть приспособлена к горизонтальному масштабированию, что бы можно было поставить +1 сервер, развернуть там еще один бекенд и вперед, т.к. вертикальное масштабирование имеет разумные пределы.
2. В качестве фронтенда лучше использовать ngnix он довольно шустро умеет отдавать статику и не плохо справляется с fcgi проксированием.
3. Модули на c\c++ приятней писать под apache, много документации, большое комьюнити, куча примеров и много почти готовых решений, код которых можно использовать для своего велосипеда.
5. Лучше использовать fastcgi, он быстрей.
6. У fastcgi — есть один нездоровый косяк, по мнению многих, до тех пор пока бекенд на другом конце пайпа не отдаст вам данные, все запросы попадают в очередь и ждут смиренно пока не будет удачного ответа или же вылета по таймауту.
7. Для того, что бы fastcgi выдавал вам максимальные возможности, ваше приложение лучше сделать атомарным, запустить несколько процессов и забить их блоком в тот же ngnix для проксирования.
распределенная нагрузка однозначно! ставьтье Piranha и наслаждайтесь!
Без разницы на чем писать, главное адекватно. Быдлокод на C++ может быть реально медленнее реализации на PHP/Python/Ruby. А вот, что делать через год два, когда пара основных разработчиков ушла и как эта вся хрень работает никто уже не помнит, совсем другой и более интересный вопрос.
Если сайта еще нет, то лучше написать его на том языке, на котором вашей команде удобней работать, а затем уже поэтапно решать проблемы производительности. Исключение из этого правила — случай, когда в обработке огромной нагрузки вся соль вашего проекта или если у вас изначально есть серьезная уверенность, что сразу же будет ОГРОМНЫЙ наплыв посетителей.
Если вам удобнее писать на C[++] — пишите на нем, таково мое мнение. Неудобно — пишите изначальную версию сайта («прототип») на скриптовых языках.
Если это не учебная задача, а реальный коммерческий проект, то при выборе языка определяющую роль играет, по моему мнению, команда программистов или перспективы по ее найму. Я не думаю, что имеющимся в вашем распоряжении программистам абсолютно пофик на чем писать — на C++ или на PHP (для примера). За редким исключением это люди с разной квалификацией (которую не стоит сравнивать напрямую, так как это разные типы языков и подходы к программированию). Это, как правило, люди с разным подходом к решению задач, с разными взглядами на “правильное” программирование. Если говорить о сформировавшихся специалистах. И поэтому, если проект делает не один человек (вы сами), то у вас вряд ли будет возможность свободно выбирать язык программирования — не задумываясь о возможностях имеющихся программистов или о перспективах по их найму (и о зарплатах для них).
Так же я уверен, что полностью тупиковый путь пытаться отдать часть работ по сайту, разрабатываемому на C++, фрилансерам или аутсорсить часть проекта внешней команде. В случае же использования «стандартных» для web подходов и скриптовых языков программирования можно часть работы отдать другой команде.
А теперь предположим, что поддержка очень высокой нагрузки с самого начала — это критическое условие для проекта. В этом случае нужно разбираться конкретно и индивидуально для каждого конкретного проекта, где именно в нем «бутылочное горло» и как его можно устранить. Не факт, что тут поможет смена языка программирования.
Например, если у вас главная сложность в содержательно высокой нагрузке на СУБД, то какая, собственно, разница, сколько микросекунд уйдет на компоновку страницы в C-программе, пока основное время теряется в глубинах СУБД? Тут проблема не на чем писать обработчики страниц/динамических запросов, а как можно ускорить базу. Можно, конечно, и от «стандартной» СУБД отказаться, всю работу перенеся в свой engine. Но это уже получается очень нетривиальный проект. Мне лично такие проекты нравятся, но только когда в них есть реальная потребность. И я понимаю, что это стоит ОЧЕНЬ больших денег и главное — потребует уйму времени.
Если же дело не в пропускной способности СУБД или TCP/IP стека, а именно в компоновке страниц, всяком парсинге, возможности “легковесного” кэширования (для которого есть возможность) и т.п., то тогда, конечно, использовать C[++] разумная идея. Можно использовать какой-то легковесный сервер (не apache) или «заготовку» сервера, которая принимает HTTP-запросы и отдает их вашей программе. Для того, чтобы не писать самим и не отлаживать высокопроизводительный модуль приема/раздачи данных по TCP и парсер HTTP. Но, конечно, если есть время, то можно заняться и этим, глядя на исходники лучших open source серверов как на пример хорошей и вылизанной годами реализации.
Если вам удобнее писать на C[++] — пишите на нем, таково мое мнение. Неудобно — пишите изначальную версию сайта («прототип») на скриптовых языках.
Если это не учебная задача, а реальный коммерческий проект, то при выборе языка определяющую роль играет, по моему мнению, команда программистов или перспективы по ее найму. Я не думаю, что имеющимся в вашем распоряжении программистам абсолютно пофик на чем писать — на C++ или на PHP (для примера). За редким исключением это люди с разной квалификацией (которую не стоит сравнивать напрямую, так как это разные типы языков и подходы к программированию). Это, как правило, люди с разным подходом к решению задач, с разными взглядами на “правильное” программирование. Если говорить о сформировавшихся специалистах. И поэтому, если проект делает не один человек (вы сами), то у вас вряд ли будет возможность свободно выбирать язык программирования — не задумываясь о возможностях имеющихся программистов или о перспективах по их найму (и о зарплатах для них).
Так же я уверен, что полностью тупиковый путь пытаться отдать часть работ по сайту, разрабатываемому на C++, фрилансерам или аутсорсить часть проекта внешней команде. В случае же использования «стандартных» для web подходов и скриптовых языков программирования можно часть работы отдать другой команде.
А теперь предположим, что поддержка очень высокой нагрузки с самого начала — это критическое условие для проекта. В этом случае нужно разбираться конкретно и индивидуально для каждого конкретного проекта, где именно в нем «бутылочное горло» и как его можно устранить. Не факт, что тут поможет смена языка программирования.
Например, если у вас главная сложность в содержательно высокой нагрузке на СУБД, то какая, собственно, разница, сколько микросекунд уйдет на компоновку страницы в C-программе, пока основное время теряется в глубинах СУБД? Тут проблема не на чем писать обработчики страниц/динамических запросов, а как можно ускорить базу. Можно, конечно, и от «стандартной» СУБД отказаться, всю работу перенеся в свой engine. Но это уже получается очень нетривиальный проект. Мне лично такие проекты нравятся, но только когда в них есть реальная потребность. И я понимаю, что это стоит ОЧЕНЬ больших денег и главное — потребует уйму времени.
Если же дело не в пропускной способности СУБД или TCP/IP стека, а именно в компоновке страниц, всяком парсинге, возможности “легковесного” кэширования (для которого есть возможность) и т.п., то тогда, конечно, использовать C[++] разумная идея. Можно использовать какой-то легковесный сервер (не apache) или «заготовку» сервера, которая принимает HTTP-запросы и отдает их вашей программе. Для того, чтобы не писать самим и не отлаживать высокопроизводительный модуль приема/раздачи данных по TCP и парсер HTTP. Но, конечно, если есть время, то можно заняться и этим, глядя на исходники лучших open source серверов как на пример хорошей и вылизанной годами реализации.
Я например рекомендовал бы такой набор (ну если деньги несомненно есть на аппаратную платформу :) ) — Itanium + HP-UX + Java.
Платформа HP-UX + Itanium обеспечит серьезную производительность и гибкость — не чета преобладающему на рынке железу.
Java в свою очередь — высокую скорость разработки, масштабируемость, гибкость, большое количество готовых компонентов и возможностей.
Платформа HP-UX + Itanium обеспечит серьезную производительность и гибкость — не чета преобладающему на рынке железу.
Java в свою очередь — высокую скорость разработки, масштабируемость, гибкость, большое количество готовых компонентов и возможностей.
Стоимость владения проектом на C/C++ (разработка (= цене хороших девелоперов * очень большое время) + сопросождение/поддержка (так же) + отсрочка запуска и зарабатывания денег) очень и очень высока.
Так что реально си нужен только в тех проектах, где по другому просто никак вообще. Например, в поисковиках (в некоторых их частях), рекламных системах и проч.
Для проектов типа хабра си точно не оправдан.
Так что реально си нужен только в тех проектах, где по другому просто никак вообще. Например, в поисковиках (в некоторых их частях), рекламных системах и проч.
Для проектов типа хабра си точно не оправдан.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
при правильном проектировании бд — нагрузку можно с неё частично снять, если не заставлять заниматься тем, что у неё не очень хорошо получается. Так, если каждый запрос в бд вынужден что то менять — я бы вообще отказался от реляционной базы (ну только для изменяемых данных, пожалуй) — реализовав все это в демоне на Си (та же бд, только не реляционная и заточенная под конкретную задачу). До сих пор вставка 10-20к рядов в рбд = почти смерть базе. А ведь по сути задача тривиальная.
Написать на С++ можно, но вопрос будет ли такая система гибкая и поддерживаемая. :\
Имеется опыт РНР сайта с кол-вом хитов в сутки (только 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 миллионов запросов, более точное распределение я вам не скажу.
Вообщем общую статистику за 24 часа lighttpd показывал на уровне 23-25 миллионов запросов, более точное распределение я вам не скажу.
видел полно PHP сайтов, которые возможно сделаны криво, и которые совершенно недержали нагрузку в виде динамической генерации контента (например photosight.ru). С другой стороны раз Psih пишет, что 25 млн. запросов держал, то нет оснований не верить.
Из своего опыта могу сказать, что такую проблему решали так (правда давно, 2002 год):
— 2 Apache-сервера только страницы отдают
— 2 сервера (БД + application) генерят «практические» статические HTML страницы и подкладывают их на 2 первых
— БД с которыми «работали» посетители тоже прекомпилировались до вида плоской таблицы
Из своего опыта могу сказать, что такую проблему решали так (правда давно, 2002 год):
— 2 Apache-сервера только страницы отдают
— 2 сервера (БД + application) генерят «практические» статические HTML страницы и подкладывают их на 2 первых
— БД с которыми «работали» посетители тоже прекомпилировались до вида плоской таблицы
1000 RPS это не так много (если речь о dedicated сервере), и легко достигается, например, на питоне.
Проблема — в базе, обращение к базе просаживает производительность сразу на порядок, а для тяжелых
запросов — на два и более. Как понимаете, эта константа от языка не зависит, и потому, делать приложение на
C++ нет никакого смысла вообще. Если посмотреть на тесты, то:
Ocsigen — 4500 — 5800 RPS (core duo что-то там)
YAWS на таком железе будет где-то 2500 — 2800 RPS
Python (мерял на нашем фреймворке) — 480 (без memcached) — 1700 (c memcached)
При том, что правильно написанные http приложения могут естественным образом масштабироваться —
то еще раз, писать на C++ не имеет смысла.
Проблема — в базе, обращение к базе просаживает производительность сразу на порядок, а для тяжелых
запросов — на два и более. Как понимаете, эта константа от языка не зависит, и потому, делать приложение на
C++ нет никакого смысла вообще. Если посмотреть на тесты, то:
Ocsigen — 4500 — 5800 RPS (core duo что-то там)
YAWS на таком железе будет где-то 2500 — 2800 RPS
Python (мерял на нашем фреймворке) — 480 (без memcached) — 1700 (c memcached)
При том, что правильно написанные http приложения могут естественным образом масштабироваться —
то еще раз, писать на C++ не имеет смысла.
Как то необходимо было переписать небольшой код, который очень порядочно нагружал сервер, PHP просто заваливал сервак (проц 100%), модуль для nginx на C++ освободил сервер, загрузка проца упала до 0.1%. Кол-во отдаваемых данных возрасло в несколько тысяч раз. Да и на C++ реально писать почти как на PHP, хотя для этого потребуется как вариант свою плаформу.
Я за С++ однозначно. Если скорость в приоритете конечно.
Про масштабируемость — какую заложите архитектуру, так и расширять получится в будующем.
Имхо, даже не особо грамотный подход СИ кодера обойдет по скорости любой скриптовый язык.
Ведь все ресурсы компа в ваших руках!
Про масштабируемость — какую заложите архитектуру, так и расширять получится в будующем.
Имхо, даже не особо грамотный подход СИ кодера обойдет по скорости любой скриптовый язык.
Ведь все ресурсы компа в ваших руках!
Имел счастье делать микс С++ memcached с генерацией данных на пхп
Как говориться — если времени мало а буста хочется…
нгинкс аксесит С++ демона, он шурстит по кешеду МАЛЕК генеря код от себя, что в кешеде на нашол передает на генерацию в пхп, который коладет это дело в кешед…
При необходимости повторить…
Развитие CacheGraph — где граф работает на С++
Местами в сотни раз быстрее и… если надо что-то изменить — меняем это в пхп и не паримся с более сложной разработкой на Сях…
(ПС — первый запуск показал что в Сях кудато утекают гдето 2-3 метра на запрос… отлов бага занял часа 4… вот по этому и считается что разработка на С долгая и дорогая — писать просто и быстро, и еще потом полгода баги правим :) )
Как говориться — если времени мало а буста хочется…
нгинкс аксесит С++ демона, он шурстит по кешеду МАЛЕК генеря код от себя, что в кешеде на нашол передает на генерацию в пхп, который коладет это дело в кешед…
При необходимости повторить…
Развитие CacheGraph — где граф работает на С++
Местами в сотни раз быстрее и… если надо что-то изменить — меняем это в пхп и не паримся с более сложной разработкой на Сях…
(ПС — первый запуск показал что в Сях кудато утекают гдето 2-3 метра на запрос… отлов бага занял часа 4… вот по этому и считается что разработка на С долгая и дорогая — писать просто и быстро, и еще потом полгода баги правим :) )
вот не понимаю. они не «куда-то утекают», а вы своими шаловливыми ручонками «куда-то про*бываете». а потом все дружно кричат, что с++ говно, у него память течет! поймите, это не у него течет, а у Вас!
На сях очень просто сделать так чтобы память утекала…
Утечки памяти — самая распространенная ошибка
Самый простой способ — ферментировать себе память.
У меня вообще проблема была другая — менеджер памяти(nedalloc) просто оставлял ее про запас, и в одном месте забыл сделать деструктор виртуальным
Утечки памяти — самая распространенная ошибка
Самый простой способ — ферментировать себе память.
У меня вообще проблема была другая — менеджер памяти(nedalloc) просто оставлял ее про запас, и в одном месте забыл сделать деструктор виртуальным
<irony>супер C++ джедай детектед </irony>
…
…
1) Стоимость сервера ниже зарплаты программиста, проще купить ещё сервер, чем нанимать ещё программистов
2) К стоимости разработки на языке плюсуйте ещё и стоимость поддержки проекта на этом языке
3) Если вам не хватает производительности на посещаемость в будущем, просто начинайте писать сейчас, когда допишите соответственные мощности будут стоить приемлемо
4) Большую часть времени веб-приложение ожидает данных, чаще всего — из базы. Какая разница на каком языке ждать эти данные?
2) К стоимости разработки на языке плюсуйте ещё и стоимость поддержки проекта на этом языке
3) Если вам не хватает производительности на посещаемость в будущем, просто начинайте писать сейчас, когда допишите соответственные мощности будут стоить приемлемо
4) Большую часть времени веб-приложение ожидает данных, чаще всего — из базы. Какая разница на каком языке ждать эти данные?
1. очень скользкий момент — крайне зависит от масштабов. Если программа планируется загрузить 1 сервак — то конечно лучше взять 3 и писать на легком языке. Если же 100 — то стоимость ещё 200 серверов явно перешкалит зп нескольких девелоперов… ну и… глобальное потепление и всё такое =).
4) Что за бред? Простые запросы выполняются достаточно быстро, к тому же есть кеширование, и выборка данных может быть куда как быстрее чем интерпретация кода на каком-нибудь руби.
Я бы советовал посмотреть на www.kegel.com/c10k.html
Там много полезной информации.
Там много полезной информации.
Наша контора имеет небольшой опыт написания высокопроизводительных веб приложений на C++, причем делали как FastCGI приложение, так и модули к Nginx. Причем на C++ писались небольшие модули, которые не взаимодействовали напрямую с БД, данные накапливаются в памяти или файле на диске, аггрегируются, время от времени опрашиваются другими модулями, обычно на PHP, которые и ложат все в базу. После непродолжительной отладки и устранения утечек все работает очень стабильно и запас по производительности огромный, надо сказать что модули на C++ не переписывались уже пару лет, в то время как другие части проекта приходится постоянно переписывать для того, чтоб поднять производительность…
Возможно, хорошим вариантом будет многослойная архитектура, при которой логика приложения реализуется на C++. Этот слой работает с данными, обрабатывая значительные объемы информации. Отдельным слоем реализован веб-фронтэнд, который, по большому счету, можно писать вообще на чем угодно. А между ними должен быть какой-то умный и гибкий интерфейс — например, кастомный модуль для PHP или Apache, или апачевский же ProxyIO. Подобный подход используется в developer.yahoo.com/geo для разработки веб-сервисов.
я бы правильно реализовал j2ee приложение (с использованием ejb, которые и придумывались для работы в кластере), сделал бы кластер и потратитил денег на промышленный Bea WebLogic (сервер приложений).
прироста производительности на C++ у вас будет не более 20%, а вопрос масштабируемости придется решать самостоятельно.
прироста производительности на C++ у вас будет не более 20%, а вопрос масштабируемости придется решать самостоятельно.
Откуда оценки не более 20% «прироста производительности на С++?»
на основе опыта. очень редко возникают тормоза из-за самого app сервера (если примые руки, конечно). как правило тормоза на стороне базы и из-за IO операций. могу судить, что как правило, чистые вычисления (операции со строками, преобразования, и т д) занимают не более 20% от времени обработки запроса. переписав эту часть можно добиться определенного прироста производительности. но не более того.
можно примерно представить картину тут (но там нету про web приложения):
www.idiom.com/~zilla/Computer/javaCbenchmark.html
можно примерно представить картину тут (но там нету про web приложения):
www.idiom.com/~zilla/Computer/javaCbenchmark.html
ну вы бы еще из библии цитату привели… компиляторная наука-то не стоит на месте, чай не щи лаптями хлебаем…
вот вам свежей данные, прослезитесь: www.stefankrause.net/wp/?p=9
вот вам свежей данные, прослезитесь: www.stefankrause.net/wp/?p=9
Да, согласен, если база является узким местом, то оптимизировать надо именно её.
Но тут речь идёт о том, чтобы свести обращения к базе к минимуму. И хочется обеспечить одновременную обработку как можно большего количества запросов. Тут уже сказывается не скорость выполнения кода, а архитектура сервера. Вы считаете, что какой-нибудь обычный Java APP-сервер сможет держать нагрузку сравнимую с асинхронным приложением (хотя бы на той же Java)?
Но тут речь идёт о том, чтобы свести обращения к базе к минимуму. И хочется обеспечить одновременную обработку как можно большего количества запросов. Тут уже сказывается не скорость выполнения кода, а архитектура сервера. Вы считаете, что какой-нибудь обычный Java APP-сервер сможет держать нагрузку сравнимую с асинхронным приложением (хотя бы на той же Java)?
я не смогу однозначно ответить на ваш вопрос. мое мнение заключается в том, что из экономических соображений стоит смотреть в сторону решений, которые изначально масштабируемы.
что такое Java? это язык, и он не native. если вы хотите на лету мандельбротта множество выдавать, то C++, конечно, будет быстрее (зависит от dev, конечно :)). но когда мы говорим о web приложениях, тут все не так однозначно.
я считаю, на сегодня экономически дешевле купить 2 сервера и использовать Java, чем писать на C++ и гордиться, что оно работает только на одной машинке. При этом оба варианта реализуемы _только_ с учетом наличия вменяемых разработчиков. Кроме того, на мой взляд, приложения на Java дешевле поддерживать.
что такое Java? это язык, и он не native. если вы хотите на лету мандельбротта множество выдавать, то C++, конечно, будет быстрее (зависит от dev, конечно :)). но когда мы говорим о web приложениях, тут все не так однозначно.
я считаю, на сегодня экономически дешевле купить 2 сервера и использовать Java, чем писать на C++ и гордиться, что оно работает только на одной машинке. При этом оба варианта реализуемы _только_ с учетом наличия вменяемых разработчиков. Кроме того, на мой взляд, приложения на Java дешевле поддерживать.
Мой товарищ последний год именно такую систему и писал-поддерживал. Из не C++ кода там был только MySQL.
В детали особо не вникал, знаю только, что там какая-то из асинхронных архитектур. Написано с использованием библиотек Boost'а.
Если у вас есть предложение удаленной работы или работы в Киеве, я думаю ему будет интересно.
В детали особо не вникал, знаю только, что там какая-то из асинхронных архитектур. Написано с использованием библиотек Boost'а.
Если у вас есть предложение удаленной работы или работы в Киеве, я думаю ему будет интересно.
Не изобретайте велосипед. Основная часть не критичной к производительности функционала пишется на «легких», интерпретируемых языках (PHP, Python...), ботелнеки реализуются на C, C++, Erlang… в виде демонов или еще как-то. Надо понимать, что языки далеко не самое главное, главное АРХИТЕКТУРА системы. 1000 конкаренси можно и на PHP сделать, можно и гораздо больше. Хороший совет — пишите на том, что знает Ваш знакомый гуру=)
Читаем тут про ebay:
www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf
Было: 3.3 миллиона строк на C++ (150 мб бинарник), достигался лимит количества методов класса. Сейчас всё переписано на Java. Вывод: важна архитектура, а если важна архитектура, то не смысла писать на C++, ибо после архитектуры важна стоимость разработки.
www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf
Было: 3.3 миллиона строк на C++ (150 мб бинарник), достигался лимит количества методов класса. Сейчас всё переписано на Java. Вывод: важна архитектура, а если важна архитектура, то не смысла писать на C++, ибо после архитектуры важна стоимость разработки.
Делали тдс-ку, нагрузку держала на порядок выше заявленной. С++ демон вешался на порт.
ЗЫ: учитывая малый круг задач, которые требуют подобной нагрузки, и функциональность не превосходит пропускную способность шины (да-да, именно поэтому желеные роутеры держат нагрузку лучше, чем софтовые из ПС), че за задача у автора такая?
ЗЫ: учитывая малый круг задач, которые требуют подобной нагрузки, и функциональность не превосходит пропускную способность шины (да-да, именно поэтому желеные роутеры держат нагрузку лучше, чем софтовые из ПС), че за задача у автора такая?
my choice: python + >1 сервера + ботлнеки на Си. Никакого С++, но при этом стоимость разработки ботлнеков не должна превышать стоимость серверов (что, если честно, почти анрил). Естественно — стопроцентно масштабируемо, по-другому попросту никак.
стоит заметить что кое-кто в комментариях просто не понимает что Си быстрее не в два раза чем тот же питон. И не в четыре… и не шесть… а ГОРАЗДО быстрее, если очень аккуратно подходить к вопросу. Там где питон на wsgi пустой helloworld выплевывал 2000rps, апач — статику — 5000rps, мой собственный минипиздрический (извините, по-другому хз как назвать) выплевывал тот же helloworld с 28000rps. Причём — относительный антиквариат AMD Athlon 3800+ (sc). Это был мой личный эксперимент выжать всё что только можно из http =). Кода там было — немеряно, на грамотную обработу при помощи sys-epoll. При попытке запустить на одной машине с ab, последний жрал 90% cpu и то не успевал скармливать всё моему демону.
Посмотрите исходники скажем set() у питона — ОЧЕНЬ и ОЧЕНЬ много кода для простой вещи. Эффективно писать на Си действительно тяжело, а только в таком случае раскрываются все прелести языка. К слову, утечки в памяти — детский сад. Один только valgrind позволяет за ними следить, не говоря уже о простых дампах. Чего в этом сложного-то?
Посмотрите исходники скажем set() у питона — ОЧЕНЬ и ОЧЕНЬ много кода для простой вещи. Эффективно писать на Си действительно тяжело, а только в таком случае раскрываются все прелести языка. К слову, утечки в памяти — детский сад. Один только valgrind позволяет за ними следить, не говоря уже о простых дампах. Чего в этом сложного-то?
>Кода там было — немеряно, на грамотную обработу при помощи sys-epoll.
откуда там кода немеряно с epoll'ом? :) Столько же, сколько и с select/poll.
если к этому добавите ещё 2.6.28 ядро + 2.10 glibc, то можете заменить все вызовы fcntl с установкой неблокирующего режима, на новые флаги в accept4/socket/итд. Что сократит ещё немного строчек(и увеличит производительность), раз вам кажется это немеряным :)
Кода на грамотное использование readv/writev вместо read/write гораздо больше получается, чем детсад с epoll'ом ) И то это всё крохи в хттп сервере…
откуда там кода немеряно с epoll'ом? :) Столько же, сколько и с select/poll.
если к этому добавите ещё 2.6.28 ядро + 2.10 glibc, то можете заменить все вызовы fcntl с установкой неблокирующего режима, на новые флаги в accept4/socket/итд. Что сократит ещё немного строчек(и увеличит производительность), раз вам кажется это немеряным :)
Кода на грамотное использование readv/writev вместо read/write гораздо больше получается, чем детсад с epoll'ом ) И то это всё крохи в хттп сервере…
и последняя лепта — стоимость мозгов таких что могут создать эффективный шедевр на Си — я даже боюсь представить сколько =). Ещё сложнее их попросту найти. Если притопать на Невский и заорать во всё горло «дам 500тр в месяц, создаёте мне супермегапрограмму на Си» — кроме шарлатанов вряд ли кто впишется. Посему, лучше python и много серверов (и ниодного мегамощного!).
Лучше сразу рассчитывать вариант с балансировкой на кучу серверов. Как бы оптимально не был написан софт, при таких количествах запросов все равно встанет вопрос масштабирования. А вот времени на C++ разработку по сравнению с Java/Ruby/PHP/Python будет потрачено несоизмеримо больше.
И еще совет — попробуй пустить сервис в обкатку как можно раньше, и ничего не оптимизируй до реального запуска. Потом уже все увидишь где и что, может что то нужно будет написать на C, но сразу туда соваться не стоит.
Я когда-то писал баннероотдавалку для баннербанка (1000 показов в секунду на железе класса P3), вообщем мой опыт такой — «узкие места» оказывались ну совершенно не там, где интеллект видел их изначально.
И еще совет — попробуй пустить сервис в обкатку как можно раньше, и ничего не оптимизируй до реального запуска. Потом уже все увидишь где и что, может что то нужно будет написать на C, но сразу туда соваться не стоит.
Я когда-то писал баннероотдавалку для баннербанка (1000 показов в секунду на железе класса P3), вообщем мой опыт такой — «узкие места» оказывались ну совершенно не там, где интеллект видел их изначально.
Лично моё мнение — надо делать простое, масштабируемое, решение с минимальным временем развёртывания, а не заморачиваться на чём это будет написано.
Под это определение подходит связка HAProxy/nginx/php+apc/memcached/memcacheQ/MySQL-Proxy/MySQL-Sharding/MySQL-Replication
Все вышеописаные технологии отлично стыкуются обеспечивая легкий scale-out
Под это определение подходит связка HAProxy/nginx/php+apc/memcached/memcacheQ/MySQL-Proxy/MySQL-Sharding/MySQL-Replication
Все вышеописаные технологии отлично стыкуются обеспечивая легкий scale-out
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Реальны ли высокопроизводительные Web-приложения на C++?