Увидел свет (http://mail-archives.apache.org/mod_mbox/httpd-announce/2011...) новый выпуск экспериментальной ветки http-сервера Apache 2.3.11, на базе которой будет сформирована стабильная ветка 2.4. Версия 2.3.11 примечательна переходом (http://mail-archives.apache.org/mod_mbox/httpd-dev/201103.mb...) на стадию бета-тестирования, на которой наращивание функциональности сменяется стадией выявления и исправления ошибок. В состав ветки 2.3.x вошли новые возможности которые невозможно интегрировать в стабильную ветку 2.2.x в силу большого размера вносимого кода, необходимости значительной переработки подсистем или из-за нарушения совместимости.
Релиз 2.3.11 включает в себя Apache Portable Runtime (APR) 1.4.2 и APR-Util 1.3.10, которые в отличие от прошлых выпусков выделены (http://httpd.apache.org/dev/dist/) в отдельный архив "-deps". В Apache 2.3.11 используется расширенны...URL: http://mail-archives.apache.org/mod_mbox/httpd-announce/2011...
Новость: https://www.opennet.ru/opennews/art.shtml?num=29857
Чуть ли не единственный проект Apache, написанный на языке программирования C++. Остальное — Java.
Представляешь, как у них руки чешутся?
Альтернатива: вынести весь C++-булшит из юзерспейса в Apache Harmony, а поверх запустить типобезопасный аппсервер Apache Geronimo. ;)
И кто будет юзать такие тормоза?
Ну так а поверх все равно nginx запускать.
А зачем поверх nginx запускать?
и то верно.
nginx нужно запускать самостоятельно. без java-кода.
а то вон даже С от С++ уже не отличают.
Чтобы не тормозило. А почему сразу не nginx - ну создан портал, использует апачевские расширения, работает, надежен. Предлагает переделывать под nginx, что еще не факт, что выйдет? Куда проще запустить его как кэширующий сервер и иметь и скорость, и фичи.
> И кто будет юзать такие тормоза?Тормоза только на старте. Дальше уже отJITится и в памяти закэшируется.
видимо после этого должна последовать реклама хостинга впс.
как в м-видио - с 4 гига, 4 яддра.
Память всегда можно использовать более еффективно чем хранить jit'овские экскременты. Кроме того, этот код ни разу не оптимизирован, потому что иначе оно бы вообще не стартовало :) В итоге - тормоза просто кошмарные.
> Память всегда можно использовать более еффективно чем хранить jit'овские экскременты.Под файловый кэш, например, ZFS использует память наиболее эффективно и отдаёт её приложениям по первому требованию. Но почему-то считается, что 90% занятого ОЗУ — недостаток. ;) Так и с JIT.
Объясните мне, почему держать незанятым 50% и более ОЗУ на сервере считается нормой?
> Кроме того, этот код ни разу не оптимизирован, потому что иначе оно бы вообще не стартовало :)
Почитайте о технологии JIT что ли.
>В итоге - тормоза просто кошмарные.
Ага: запустил один раз -> тормозит -> плохая технология. А вы не в курсе, что первый запук не показатель, что рантайм системе требуется собрать статистику по исполнению кода в интерпретативном режиме, чтобы произвести оптимизацию JIT для долговременной работы?
> Объясните мне, почему держать незанятым 50% и более ОЗУ на сервере считается нормой?Потому что малейший всплеск активности - и вся скворечня накроется медным тазом. Внезапный всплеск на 100-300% - это уже за рамками нормы. Повод для анализа. Но +/- 10..15% - это обычное дело. И когда в системе весь доступный НЗ - это 10%... Сам наверное должен понимать. Вроде не мальчик уже. Хотя хбз.
>> И кто будет юзать такие тормоза?
> Тормоза только на старте. Дальше уже отJITится и в памяти закэшируется.Угу, только вот незадача: полный JIT всего и вся на развесистом коде может увеличить потребление памяти приложения на много сотен мегабайт, к тому моменту, когда "все отJITится". Или никогда не видели java-приложения, у которого при -Xmx200m потребление памяти через пару недель зашкаливает за гиг при использовании java -server, которая "все отJITтит"?
А тормоза и потом, знаете ли. Сколько хипа не выделишь, с тем, как типичный джава-код постоянно создает объекты, постоянно кто-то будет его хотеть, значит GC будет постоянно чистить от шлака, и на крупном приложении, когда хипа много можно такие залипоны получить от GC, что тормоза при старте покажуется сказкой.
>А тормоза и потом, знаете ли. Сколько хипа не выделишь, с тем, как типичный джава-код постоянно создает объекты, постоянно кто-то будет его хотеть, значит GC будет постоянно чистить от шлака, и на крупном приложении, когда хипа много можно такие залипоны получить от GC, что тормоза при старте покажуется сказкой.Профилирование кода для продакшена никто не отменяет. И, да, "утечки" памяти для Java тоже никто не отменял, профилировщик как раз и показывает, где неэффективно создаются и уничтожаются объекты. Чаще это происходит не в системных библиотеках и аппсерверах (они-то как раз отлично поднастроены, чтобы избегать такого), а в пользовательских бинах.
Вот, блин, а нам всю жизнь рассказывали, что Апач на православном C написан. А он на богомерзком C++, оказывается. Кто ошибся? Исходники моего 2.2.x на C, и компилятся подозрительно быстро для C++-проекта.
> Вот, блин, а нам всю жизнь рассказывали, что Апач на православном C
> написан. А он на богомерзком C++, оказывается. Кто ошибся? Исходники моего
> 2.2.x на C, и компилятся подозрительно быстро для C++-проекта.Правда что ли? Ну значит я лажанулся насчёт "написан на C++". Исправляюсь: "Чуть ли не единственный проект Apache, написанный на языке программирования C".
К чему эти полумеры? Исправляться так уж полностью: "Чуть ли не единственный проект Apache" ;)
> Чуть ли не единственный проект Apache, написанный на языке программирования C++. Остальное — Java.Блин, я все понимаю и можно много не знать и пр. Но лохануться *так сильно* - это где-то на грани. Не знать, что апач - это чистый C и при этом пытаться гнуть пальцы на опеннете - это сильно.
>> Чуть ли не единственный проект Apache, написанный на языке программирования C++. Остальное — Java.
> Блин, я все понимаю и можно много не знать и пр. Но
> лохануться *так сильно* - это где-то на грани. Не знать, что
> апач - это чистый C и при этом пытаться гнуть пальцы
> на опеннете - это сильно.Ну не удалось протроллить сиплусплусников. Да. Лажанулся.
Помогает не иметь троллинг целью. Это разве что средство, и то сомнительное. Trust me.PS: до сих пор сижу на 1.3.x (про EOL в курсе), и как-то на 2.x неохота -- потребление памяти чуть ли не как у джа... ой. В общем, неразумное какое-то как для прослойки между nginx и mod_{security,php,perl}.
Но зачем? fastcgi же
> Помогает не иметь троллинг целью. Это разве что средство, и то сомнительное. Trust me.Помогает обычно иметь голову на плечах, и не говорить о том, чего не знаешь :)
P.S: iZEN - ты уже дописался на джаве. У тебя мозги тормозят так же, как и виртуальная машина у любимого тобой языка программирования.
Пробуксовывают, а не тормозят.
>Чуть ли не единственный проект Apache, написанный на языке программирования C++. Остальное — Java.видимо поэтому он чуть ли не единственный из проектов Apache, который кому-то реально нужен.
зыж
это может показаться жабисту смешным, но С (на котором написан апач) немножко отличается от С++ (на котором НЕ написан апач)
>>Чуть ли не единственный проект Apache, написанный на языке программирования C++. Остальное — Java.
> видимо поэтому он чуть ли не единственный из проектов Apache, который кому-то
> реально нужен.
> зыж
> это может показаться жабисту смешным, но С (на котором написан апач) немножко
> отличается от С++ (на котором НЕ написан апач)Apache ни разу не понадобился, поэтому не учёл того, что многопоточность в Apache2 реализована РУКАМИ, а не с помощью библиотек C++. Думал, что всё-таки использовали достижения C++ на поприще многопоточности, а оказывается нет.
> Apache ни разу не понадобился, поэтому не учёл того, что многопоточность в Apache2 реализована РУКАМИ, а не с помощью библиотек C++. Думал, что всё-таки использовали достижения C++ на поприще многопоточности, а оказывается нет.Уууйди а?! Перл за перлом и все перловее... Не позорься pls.
>> Apache ни разу не понадобился, поэтому не учёл того, что многопоточность в Apache2 реализована РУКАМИ, а не с помощью библиотек C++. Думал, что всё-таки использовали достижения C++ на поприще многопоточности, а оказывается нет.
> Уууйди а?! Перл за перлом и все перловее... Не позорься pls.Замолкаю.
единственно здравая мысль.зыж
хоть бы сабж читнул что ли. даже не источник, а этот, местный.
а вообще, эффективную схему mpm http://httpd.apache.org/docs/2.2/mod/worker.html сейчас на С (и уж тем более на С++) реализовать гораздо проще чем на жабе.
в ц++ как бе нет многопоточности. им это не надо.
>в ц++ как бе нет многопоточности.В "ц++" (также как и в "це") есть всё, что позволяет ОС и почти всё, что позволяет железо (в отличие от...). Другое дело, что далеко не все могут это нормально использовать )))
тогда не надо говорить чо ц++ подходит для кроссплатформеной разработки.
Ага, еще скажи, что SMP всякие в ядрах на C++ делаются :)
>>Чуть ли не единственный проект Apache, написанный на языке программирования C++. Остальное — Java.
> видимо поэтому он чуть ли не единственный из проектов Apache, который кому-то
> реально нужен.У них ещё есть Hadoop, который многим нужен. Почему-то написан на Java.
> У них ещё есть Hadoop, который многим нужен. Почему-то написан на Java.PHP тоже "многим нужен".
>>многим нужен. Почему-то написан на Java.
> PHP тоже "многим нужен".Да! И не "написан на джабба". Мы его помали?
Subversion не на C++, imho.
> mod_lua - позволяет интегрировать в httpd интерпретатор языка LuaКтонить может привести пример, где эта фича будет полезна?
Например для более изощренного контроля доступа или переписывания урлов, чем позволяют другие модули апача. Примерно тоже, что может делать в этом вопросе mod_perl. Но не для написания на lua сайтиков по аналогии с mod_php.
Это еще вопрос! Есть такой штук -- Prosody.IM -- весьма занятная штука. Модули под него на Lua. Один из них, кстати, поднимает FastCGI вэб-сервак.
Вот видать для подобных вариантов -- чтоб можно было заинтегрировать Prosody.IM и Apache -- такое и может пригодиться.
Потому тут получится не то что сайтик на lua --- а целая jabber ферма.
На встроенных системах.
> На встроенных системах."Встроенных", боже... На "встроенных" нет никаких апачей и быть не может.
может, если я встрою. ничто не мешает
Ну да, так и винду модно встроить, ага.
> Ну да, так и винду модно встроить, ага.Ну так и встраивают, ага. И как правило вполне себе удовлетворительно работает.
>mod_remoteip - заменяет значение IP-клиента на содержимое из определенного HTTP-заголовка (например, X-Client-IP или X-Forwarded-For). Обычно модуль используется при работе apache в роли бэкенда;Тоже хорошо, отдельно мод_рпаф собирать не придётся для бекендов, да о рейтлимит встроили, обрастают встроеными рюшечками, облегчая сборку - не надо вспоминать какие модули и к чему прикручивал ...
Вот чего не видно -- будет ли сие поддерживать технологию web-socket хотя бы на уровне APE-Servers. Было бы не плохо...