Анонсирован (http://www.apache.org/dist/httpd/Announcement2.2.html) выход релиза HTTP сервера Apache 2.2.4.
В новом релизе исправлено (http://www.apache.org/dist/httpd/CHANGES_2.2) множество мелких недоработок в различных модулях apache.URL: http://www.apache.org/dist/httpd/Announcement2.2.html
Новость: https://www.opennet.ru/opennews/art.shtml?num=9471
Это конечно классно, но я так и не завёл виртуальные хосты под ним, юзаю 1.3.37, вроде всё хорошо и так...
никаких проблем с виртуальными хостами не испытываю
Apache-2.2.3
Не, там нет проблем, просто я не смог настроить, туплю. В 1.3.37 без проблем.
а я его вообще не юзаю - зачем мне этот слон?
Ну это когда у тебя один сайт, может и можно юзать аналог, а вот когда их дофига, и некоторые - довольно тяжелые, тогда без вариантов. Да и понятный он, конфигурируется хорошо...
> а вот когда их дофига, и некоторые - довольно тяжелые, тогда без вариантов.
Интересны количественные параметры "дофига" и "довольно тяжёлые".1.3.x на Linux 2.4 (связка вполне сознательная) "сам по себе" таскал и весьма тяжёлые вещи вроде TYPO3 на загруженном и другими задачами Duron 800/512M, вот только спасалось оно сперва mmcache, потом ещё и nginx перед апачем. Всего виртхостов тогда было не дофига, но несколько десятков.
По части таскания "дофига довольно тяжёлых" апач скорее так себе, его сила -- в модульности => универсальности => как платформы. При этом как backend он заметно лучше, чем frontend.
2.2.x, правда, пока толком не щупал и тем более на production не сажал, хотя работы уже запланированы (заодно более точно посравниваем 1.3 и 2.2 на нужном).
PS: disclaimer: если бы мне апач совсем не нравился, я бы 1.3.x в альте не поддерживал :-)
Не поддерживал в смысле не сапортил в компании Alt Linux ? Не совсем понятно.
На счет дофига - я в принципе и подразумевал несколько десятков, под довольно тяжелыми - движки типа Invision Power Board и т.п..
Слова ваши довольно вразумительны, так что спасибо за комент.
>Не поддерживал в смысле не сапортил в компании Alt Linux ? Не совсем понятно.
Та ни. Я работаю в совсем другой конторе, мы в Киеве занимаемся миграцией на линукс и кластерами. Но дружим в т.ч. и с альтами.Ну и как один из пользователей пакета apache решил его подхватить, когда предыдущий майнтейнер сосредоточился на samba (Саша Боковой, думаю, многим известен как samba hacker). А дальше коллеги, у которых нагрузки на хостинг заведомо несравнимы с моими, надоумили, что делать, когда и мои расти начали. :-)
> спасибо за комент.
Welcome. BTW про apache и nginx (и не только) есть на http://www.freesource.info/wiki/
>А дальше коллеги, у которых нагрузки на хостинг заведомо несравнимы с моими, надоумили, что делать, когда и мои расти начали. :-)Может теперь вы нас надоумите?
Статейкой или тыканием тут стороны, в которую производилась оптимизация.
>>А дальше коллеги, у которых нагрузки на хостинг заведомо несравнимы с моими, надоумили,
>>что делать, когда и мои расти начали. :-)
>Может теперь вы нас надоумите? Статейкой или тыканием тут стороны,
>в которую производилась оптимизация.
Так упомянул же: для хост-системы -- оптимизация I/O[0/1], для веб-сервера -- разнесение задач frontend (лёгкая по ресурсам обработка соединений и статики) и backend (работа веб-приложений)[2], для php-приложений -- кэширование скриптов[3,4].Про питоньи и в частности Zope не скажу, почти/давно не сталкивался (как и с Resin/Tomcat).
SQL-базы тоже особенно не тюнил, хотя был изрядно удивлён тем, как полезно для того же MySQL посмотреть my-large.cnf (Pg не подгибал со времён 7.1). Про индексы сейчас по большей части к веб-разработчикам, при этом нередкие уникумы про них попросту забывают...
Есть ещё не-SQL-базы, для многих задач может оказаться гораздо лучше иерархическая, чем RDBMS (типичный признак -- когда один из атрибутов является селектором типа другого атрибута, поскольку количество таковых на кортеж может меняться и зачастую требуется уметь несколько однотипных значений на запись -- например, "телефон"). В одном таком проекте думали нарисовать прототип с использованием Sanchez GT.M[5] (к ней были PHP bindings), но в итоге решили не распыляться -- отвечать за разработку было человеку, который хорошо работал на PHP/Perl+PgSQL. На Cache[6] не смотрели.
[0] http://tldp.org/HOWTO/Multi-Disk-HOWTO.html (рекомендую для любой платформы)
[1] http://people.redhat.com/~alikins/system_tuning.html (старенькое, но работает)
[2] http://www.freesource.info/wiki/AntiApache?show_comments=1 (Денис резковат, но...)
[3] http://turck-mmcache.sourceforge.net/ (не поддерживается, но с php4 точно работает)
[4] http://eaccelerator.net/ (продолжение mmcache, рекомендуют, не пробовал)
[5] http://www.sanchez-gtm.com/ (high-end иерархическая база данных)
[6] http://www.intersystems.ru/ (российская коммерческая разработка)
2.2.3 очень хорош, разработчики контента которые у меня его юзают очень довольны
ну у меня раньше djbocha.com.ru когда был один на этом сервере, работал нормально. Там был PHP4, сайт на e107 и база MySQL5 - всё летало. А потом понадобилось пределать еще один сайтик - и всё, не вышло запустить виртуальные хосты. Поставил 1.3, всё заработало, поменял потом PHP на пятый - и с тех пор так и стоит, работает, проблем нет. Хотя говорят, когда сайтов действительно много, а не пять-десять, тогда второй апач лучше справляется. Но мне это пока не грозит.
Тю, так конечно, в e107 одни дырки тяжёлые (увесистых _полезных_ при нагрузке вещей вроде приличного темплейто-кэшевого движка что-то там не припомню). А пять-десять виртхостов -- это копейки (и один может понадобиться разносить по машинкам, но тут явно не о том речь).Возьмите mmcache или eAccelerator, потюньте элеваторы (эээ... фря... оно там вообще тюнится?) -- тоже полегчать должно. Про индейско-сысоевский бутерброд -- см. рядом.
Раньше использовал апач 2.0.59, был доволен, но когда виртуальных хостов стало больше 100 при добавлении новых апач просто не запускался, пришлось перейти на 1.3.37.
у меня тоже сейчас приближается к 100, если есть проблема надо будет думать в сторону какого нибудь модула для массового хостинга, на 1.3 не хочу возвращатся 2.2 реально быстрее работает (хотя любит кушать память).
Посмотрите nginx.org -- хорошая штука, если обычно болтается сотня-другая httpd (и кушает память). Может остаться десяток апачей при улучшении времени отклика, да и сжатие с отдачей статики (sendfile) на него стоит перекинуть.Если линукс и с питанием всё хорошо, сильно рекомендую для раздела с данными XFS (различие с ext3 под нагрузкой -- разительное). Но тогда стоит помнить, что при сбоях могут быть забиты нулями заподозренные в "утечке" блоки (убитые внутри файлы, внешне -- по метаданным -- "как живые"). Бишь UPS с обратной связью, бэкап и стабильное железо, но результат того стоит.
Также старая, но стоящая прочтения до сих пор статья: http://people.redhat.com/alikins/system_tuning.html
>Раньше использовал апач 2.0.59, был доволен, но когда виртуальных хостов стало больше
>100 при добавлении новых апач просто не запускался, пришлось перейти на
>1.3.37.
Имею почти 1000 виртуалхостов под 2.2.3-worker и не имею проблем. Не могу сказать, что каким-то особым образом тюнил апач - просто всё работает.
А оно как правило так и есть в реальности. В некоторых случаях получается что через задницу что-то настроят а потом кричат, что глюкавый софт, платформы и т.д..
У нас тоже много виртхостов (150+).. всё работает как часики.. дополнительно ничего не ставилось и не трогалось.. Увидели что при нагрузках всё нормально работает - и, как говорится "Не лезь в работающую систему(с)".
А у меня он вообще не запускается... =(((