Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 78
То есть этот пользователь «запирается» в своем каталоге и никакие скрипты никуда попасть не смогут, при учете того что вы правильно настроили операционную систему. Замечу, что многие файлы настроек по умолчанию в debian открыты для чтения для всех!!!..
Было бы неплохо, если бы вы в статью добавили о запирании, и о том, как запретить чтение этих файлов настроек. Ибо простая установка apache2-mpm-itk просто заставляет apache работать с правами определенного пользователя, и не запирает его, собственно, никуда. Писать кроме разрешенных мест он не сможет, а вот погулять по серверу с доступом к чтению — запросто.
Всё огонь, но возникает вопрос: в аннотации статьи звучит «в этом цикле статей вы узнаете как грамотно настроить LAMP сервер» а получается «вот вам мои правильные конфиги». Ну, может тогда всё в одной статье сложить или рассказать помедленнее, как и на основании чего выставлялись параметры, как вы мерили изменения в производительности, чем делали нагрузочные тесты и т.д. Иначе это получится куцый howtoforge.
В любом случае, спасибо за «чужие конфиги», почитаю продолжение, а сейчас поищу про
В любом случае, спасибо за «чужие конфиги», почитаю продолжение, а сейчас поищу про
proxy_set_header range и жива ли эта уязвимость. Просим, просим.
Вот ссылка про Range. Про проблемы изложения я понял, будем корректировать.
Спасибо, я тоже это видел год назад, когда меня это не касалось. Я про другое. Все решается установкой версий 2.2.21 (2.0.65) и выше, а в репозиториях уже 2.4 нормально забирается не первый день. Если есть баг-фикс в виде костыля, не дурно почитать про него перед применением. 15 минут и у вас исчезнут лишние строки конфигов со всеми бонусами. Пилим дальше.)
А зачем устанавливается php-dev?
А почему вы спрашиваете? В нем лежит phpize без которого не будет счастья.
Это некорректно. Правильно будет собрать пакет и поставить его.
pecl это инструмент — скачать исходники и скомпилить.
Пакеты — это круче. Есть возможность сразу посмотреть что стоит и какой версии. Словить баг несовместимости резко уменьшается. Также иметь на сервере что-либо компиляющее, собирающее — это не очень хорошо.
Плюс, собрав пакет, ты сам и только ты отвечаешь за совместимость.
Если втыкать пекловские штуки, то очень скоро начнется бардак и странные глюки. Есть расширения вообще без совместимости, без прямой и обратной. Например, php-amqp сменило версию а вместе с этим рухнуло все, так как совсем изменился интерфейс.
Также пакет тиражировать и деплоить удобнее. Десять и больше машин — вешалка.
Также не всегда есть интернет. Зачем он на бекенде?
Также пекловские штуки зачастую зависят от других, например request-control зависит от net-url. Эти зависимости не всегда очевидны и есть шанс зафакапиться после деплоя.
Вот за что я руби не люблю, кстати, так это за вот такие вот кренделя типа джемов. Пекл туда же.
Пакеты — это круче. Есть возможность сразу посмотреть что стоит и какой версии. Словить баг несовместимости резко уменьшается. Также иметь на сервере что-либо компиляющее, собирающее — это не очень хорошо.
Плюс, собрав пакет, ты сам и только ты отвечаешь за совместимость.
Если втыкать пекловские штуки, то очень скоро начнется бардак и странные глюки. Есть расширения вообще без совместимости, без прямой и обратной. Например, php-amqp сменило версию а вместе с этим рухнуло все, так как совсем изменился интерфейс.
Также пакет тиражировать и деплоить удобнее. Десять и больше машин — вешалка.
Также не всегда есть интернет. Зачем он на бекенде?
Также пекловские штуки зачастую зависят от других, например request-control зависит от net-url. Эти зависимости не всегда очевидны и есть шанс зафакапиться после деплоя.
Вот за что я руби не люблю, кстати, так это за вот такие вот кренделя типа джемов. Пекл туда же.
Зачем здесь Apache? Вы конечно привели две ссылки, одна двухгодичной давности для Wordpress, при этом обе не рассматривают работу через nginx вообще.
А можете рассказать про настройку своего named-сервера для LAMP'овой связки?
sudo vim /etc/hosts
Тогда уж:
Но интересует более тонкая настройка, а, так же, как это прописать на своей машине, так чтобы она работала через LAMP'овый сервер. Пытался настроить named на FreeBSD, и прописать ip сервера в качестве DNS на Windows машине, но, почему-то, не захотел резолвить нормально домены.
sudo vim /etc/namedb/named.conf
sudo service named restart
Но интересует более тонкая настройка, а, так же, как это прописать на своей машине, так чтобы она работала через LAMP'овый сервер. Пытался настроить named на FreeBSD, и прописать ip сервера в качестве DNS на Windows машине, но, почему-то, не захотел резолвить нормально домены.
Знаете. я в свое время заворачивался с bind9. Ничего тонкого я с ним не умею, ровно как и с другими DNS серверами. Единственное что я понимаю, что то за что отвечает каждая запись в корневой записи домена. Это все что я знаю.
Теперь я понял, что гораздо стабильнее просто купить DNS серверы либо воспользоваться help.yandex.ru/pdd/hosting.xml
> В случае на моем продакшн сервере, DNS проблемы решает сервера датацентра.
> В моем домашнем случае на wartur.ru это решает хвостовая машина на windows server 2008R2 + secondary на nic.ru
Теперь я понял, что гораздо стабильнее просто купить DNS серверы либо воспользоваться help.yandex.ru/pdd/hosting.xml
> В случае на моем продакшн сервере, DNS проблемы решает сервера датацентра.
> В моем домашнем случае на wartur.ru это решает хвостовая машина на windows server 2008R2 + secondary на nic.ru
Сам сижу настраиваю LAMP на FreeBSD только, используя разные истночники, в частности примерно по этой статье под CMS Joomla.
Там правда в качестве web-сервера nginx, а я данный пункт пропускаю и ставлю apache.
А тут в статье усмотрел что перед апачем еще и nginx выставили.
Пока один раз статью прочитал, но пока не понял стоит ли изголятся так же. (про то что ресурсы меньше должно есть, я понял).
Но что-то не дошло.
Вообщем продолжаете писать, это как минимум интересно.
И лучше как-то попонятнее.
Спасибо
Там правда в качестве web-сервера nginx, а я данный пункт пропускаю и ставлю apache.
А тут в статье усмотрел что перед апачем еще и nginx выставили.
Пока один раз статью прочитал, но пока не понял стоит ли изголятся так же. (про то что ресурсы меньше должно есть, я понял).
Но что-то не дошло.
Вообщем продолжаете писать, это как минимум интересно.
И лучше как-то попонятнее.
Спасибо
nginx нужно настраивать не на тупое проксирование запросов к Apache, а на избирательное — с отдачей статики он справляется куда лучше последнего, а Apache должен обрабатывать только динамику… Вопрос cтоит поставить так: есть ли смысл поднимать Apache, раз уж подняли nginx. Реальный плюс для многих — .htaccess файлы сторонних или унаследованных движков работают «из коробки», да и php скрипты могут быть рассчитаны на какие-то особенности Apache. других плюсов не знаю. По крайней мере в том что касается работы как «запускалки» php/
Вот я тоже подумал что пока не знаю «особенностей» использования CMS Joomla в связке с веб-сервером Apache не ставить пока nginx. Как-нить попробую поставить ее только с nginx
Я писал о том, стоит ли вставлять Apache между nginx и php. nginx стоит ставить всегда (ну, в типичных случаях точно), вопрос нужен ли после него Apache как запускалка php-скриптов или можно довериться php-fpm, возможно переписав .htaccess согласно синтаксису и духу (немаловажно) nginx. Для Joomla думаю, найти идеальные конфиги для nginx труда найти не составит.
Спасибо за начало цикла статей. Очень интересно будет почитать. Очень обрадовали DotDeb.
Для тех, кто всё-таки думает, что апач у нас тут лишний: github.com/garex/puppet-module-nginx
Кто англицкий не знает — копируйте в гугл-транслейт (он не хочет https переводить, подлец).
Апач, он конечно молодец, но пенсионный возраст ему уже подошёл, а держать апач только за ради php — расточительно ИМХО.
Кто англицкий не знает — копируйте в гугл-транслейт (он не хочет https переводить, подлец).
Апач, он конечно молодец, но пенсионный возраст ему уже подошёл, а держать апач только за ради php — расточительно ИМХО.
Многие держат apache не только из-за php но и из-за mod_rewrite
… Не холивара ради, а токмо волею пославшея мя жены…
nginx.org/ru/docs/http/ngx_http_rewrite_module.html#rewrite
Я в своё время с апачевскими рерайтами тоже не с ходу разобрался — что те, что эти не особо очевидны. Но есть некие сервисы, которые чудесным образом превращают рерайты апача в нгинкса. Естественно, что это всё не факт, что оптимально, но далее уже человеку разобраться можно.
Апач ведь развращает .htaccess`ами, а потом диски стонут от миллиардов stat`ов (кто без .htaccess`ов всё делает, а include`ами — тот молодец).
nginx.org/ru/docs/http/ngx_http_rewrite_module.html#rewrite
Я в своё время с апачевскими рерайтами тоже не с ходу разобрался — что те, что эти не особо очевидны. Но есть некие сервисы, которые чудесным образом превращают рерайты апача в нгинкса. Естественно, что это всё не факт, что оптимально, но далее уже человеку разобраться можно.
Апач ведь развращает .htaccess`ами, а потом диски стонут от миллиардов stat`ов (кто без .htaccess`ов всё делает, а include`ами — тот молодец).
Главное при этом на забыть AllowOverride None прописать, тогда на .htaccess-ы внимание сервера тратиться не будет.
Правда, нагрузка от stat-ов не душит особо, есть же кеш ФС, а вот отработка их — это, да, проблема, так что — include наше все :)
Правда, нагрузка от stat-ов не душит особо, есть же кеш ФС, а вот отработка их — это, да, проблема, так что — include наше все :)
Дык. Но это тогда lurkmore.to/Пчёлы_против_мёда
Я вообще думаю, что д.б. некий принцип тов. Паретто — 80% задач решать nginx`ом, а если 20% оставшихся может решить апач (какие-нить хитрые модули в сложной инфраструктуре), то тогда его туда и ставить. Если всё можно повесить на nginx — вешаем смело.
Опять же зависит от нашей лени. Но лень — это хорошо, ибо она наш двигатель.
Я вообще думаю, что д.б. некий принцип тов. Паретто — 80% задач решать nginx`ом, а если 20% оставшихся может решить апач (какие-нить хитрые модули в сложной инфраструктуре), то тогда его туда и ставить. Если всё можно повесить на nginx — вешаем смело.
Опять же зависит от нашей лени. Но лень — это хорошо, ибо она наш двигатель.
Ну пока ничего особенного не увидел в статье.
Не совсем понятно только, зачем изголяться с репами по Debian, если есть сам по себе неплохой уже Ubuntu Server?
Не совсем понятно только, зачем изголяться с репами по Debian, если есть сам по себе неплохой уже Ubuntu Server?
Потому что Ubuntu сервер — это испорченный дебиан. Сколько с ним не имел дела, столько и плевался. ИМХО, конечно.
Что конкретно там испорчено? Тезисами. С приведением примеров.
Очень странно. Потому как никаких проблем с ним ни разу не было. Поставил недавно как раз 12.10 на роль вэб-сервера, смотрел что вырезать лишнего — ничего особо и не выпилил. А в плане свежести репозитариев и удобства настройки никаких нареканий.
Правильный дебиан — это устаревшие на три года пакеты и половина системы пересобрать, чтобы что-то вышедшее погода назад поставить? нуну
Если для вас новизна это приоритет, то вы можете сами собирать деб пакеты и ставить, либо fetchinstall юзать.
ИМХО стабильность частенько становится важнее нежели новизна пакетов в котором еще есть баги.
У меня опыт работы на оборот, от ubuntu server головной боли больше было чем от debian
ИМХО стабильность частенько становится важнее нежели новизна пакетов в котором еще есть баги.
У меня опыт работы на оборот, от ubuntu server головной боли больше было чем от debian
Но в статье-то все равно упоминается репозиторий со свежими пакетами для дебиана. В чем разница тогда с ubuntu сервер?
Все почему-то хвалят стабильность дебиана, а сами при этом пользуют дотдеб, уиззи. И самосборное, с глибц из тестинга, протобуфом из альфы дебиана и прочее. В том то и дело, что надо полсистемы обновить, чтобы собрать что-то мало-мальски серьезное в дебиане.
Хайлоад мы делаем на убунте. Стабильность без нареканий.
Есть проблемы, конечно, но быть на самой грани разработки и использовать новейшие версии софта — дает профит куда больше.
Да и глюки там такие же консервативные, как и хваленая стабильность. Например, груб, который при установке затупляет, когда дисков больше чем один.
Хайлоад мы делаем на убунте. Стабильность без нареканий.
Есть проблемы, конечно, но быть на самой грани разработки и использовать новейшие версии софта — дает профит куда больше.
Да и глюки там такие же консервативные, как и хваленая стабильность. Например, груб, который при установке затупляет, когда дисков больше чем один.
Дайте впечатляющих примеров. Никакой беды от Ubuntu Server на продакшене пока не встретил. Более свежий софт — бедой не считаю.
evr1ka
Конечно оно того стоит, как минимум — это уменьшение нагрузки на выдачу статического контента, и возможности по его кешированию.
Как второй из возможных аргументов — отсутствие атак связанных с «медленным» клиентом.
И как третий, — иногда можно использовать чистый ngnix без apache, но это уже актуально на собственных проектах.
Конечно оно того стоит, как минимум — это уменьшение нагрузки на выдачу статического контента, и возможности по его кешированию.
Как второй из возможных аргументов — отсутствие атак связанных с «медленным» клиентом.
И как третий, — иногда можно использовать чистый ngnix без apache, но это уже актуально на собственных проектах.
Ничего не хочу сказать, но LAMP — это Linux + Apache + MySQL + PHP. У Вас же связка чуть сложнее, за счет nginx. Отразите это, пожалуйста, в заголовке: искать станет проще (и тот, кому надо Nginx + LAMP, найдет эту статью), а люди, которым именно LAMP и нужен, не станут и пробовать.
За статью спасибо за то, что разрисовали поток объемов данных, для многих начинающих это хороший повод задуматься.
За статью спасибо за то, что разрисовали поток объемов данных, для многих начинающих это хороший повод задуматься.
Статья устарела еще до написания.
Был бы рад прочитать «обновленную».
Апач убрать, php-fpm поставить для начала? Ну сколько можно-то. LAMP уже давно вчерашний день.
Подумаю. Если чего соображу напишу «обновленною» статью =). Но сейчас я уже наметил цель, поэтому давайте сначал её выполним. Fпач убрать будет наверняка просто, я практически уверен.
У меня такой вопрос. Дайте почитать, как сделать переключение пользователей ака MPM-ITK. Я буду очень благодарен вам.
У меня такой вопрос. Дайте почитать, как сделать переключение пользователей ака MPM-ITK. Я буду очень благодарен вам.
Акей. Это действительно второй разумный аргумент, после реврайтов. Сколько у вас там пользователей? И так ли оно надо — выполнять все штуки из под разных? Ну действительно, в реалиях 5.3-5.4?
nginx действительно не умеет запускать пэхэпешэчку от разных uid-gid, но там есть пулы, которые умеют.
И я еще за свою жизнь очень мало видел задач, где это действительно необходимо. Зато 99% времени я больше не парюсь про память. Апач меня заставлял мало спать и много переживать, а иногда даже ездить в датацентр.
nginx действительно не умеет запускать пэхэпешэчку от разных uid-gid, но там есть пулы, которые умеют.
И я еще за свою жизнь очень мало видел задач, где это действительно необходимо. Зато 99% времени я больше не парюсь про память. Апач меня заставлял мало спать и много переживать, а иногда даже ездить в датацентр.
Тут вообще интересно все. Я общаюсь с сервисами, которые жмут 1500-10000 рпс. Фактически без проблем.
Апача сколько там выдаст?
И я еще помню, как мы корячили апача поверх апача над апачем, чтобы хоть как-то оно работало. Не помогло ))
Аргументов как было два, так и осталось. Реврайты и пресловутый php под разными uid-gid. Реврайты уже неактуально. А разные uid-gid? Если только совсем на безбашенном шаредхостинге.
Ну не знаю. Выгода-то где. Есть она вообще?
Зато на nginx можно программировать и показывать чудеса, если собрать с правильными модулями. async, nonblocking highload и ничего никуда не течет и очень предсказуемо.
Апача сколько там выдаст?
И я еще помню, как мы корячили апача поверх апача над апачем, чтобы хоть как-то оно работало. Не помогло ))
Аргументов как было два, так и осталось. Реврайты и пресловутый php под разными uid-gid. Реврайты уже неактуально. А разные uid-gid? Если только совсем на безбашенном шаредхостинге.
Ну не знаю. Выгода-то где. Есть она вообще?
Зато на nginx можно программировать и показывать чудеса, если собрать с правильными модулями. async, nonblocking highload и ничего никуда не течет и очень предсказуемо.
Мои личные эксперименты на реальных php-скриптах показали, что mod_php и php-fpm привносят минимальный и примерно одинаковый оверхид. Если одинаковое количество воркеров и оперативки хватает с запасом, то примерно одно количество запросов будет в секунду обрабатываться. Другое дело, что mod_php требует несколько больше памяти, а значит при прочих равных при php-fpm можно поднять несколько больше воркеров (не всегда имеет смысл) или просто отдать освободившуюся память под различные кэши.
В общем в пользу Apache+mod_php простота деплоя сторонних и унаследованных скриптов, где в .htacces хитрые настройки, а в пользу php-fpm некоторая экономия оперативки и чувство, что не плодишь сущности сверх необходимого. Последнее для меня важнее даже кэшей и простоты :)
В общем в пользу Apache+mod_php простота деплоя сторонних и унаследованных скриптов, где в .htacces хитрые настройки, а в пользу php-fpm некоторая экономия оперативки и чувство, что не плодишь сущности сверх необходимого. Последнее для меня важнее даже кэшей и простоты :)
Это если нет нагрузки и в синтетических тестах. В реалиях с нагрузкой apache неконтролирируем, жрет память и в итоге забирает с собой сервер, на который даже залогиниться не получится.
А если внутри присутствует говнокод, например древняя пэхэпешечка, спортированная на новую версию, с непофикшенными депрекейтедами и варнингами, то апач просто так кошмарит, даже без нагрузки. У меня есть несколько проектов, которые мы до сих пор не можем смигрировать на nginx+php-fpm, это сплошная головная боль.
Хотя, знаю шаредхостинги, где все хорошо.
Простите, я уже привык думать в первую очередь про нагрузку и много серверов, в таком мироощущении апачу точно не место ))
А если внутри присутствует говнокод, например древняя пэхэпешечка, спортированная на новую версию, с непофикшенными депрекейтедами и варнингами, то апач просто так кошмарит, даже без нагрузки. У меня есть несколько проектов, которые мы до сих пор не можем смигрировать на nginx+php-fpm, это сплошная головная боль.
Хотя, знаю шаредхостинги, где все хорошо.
Простите, я уже привык думать в первую очередь про нагрузку и много серверов, в таком мироощущении апачу точно не место ))
Не знаю как насчет экономии памяти — у нас ситуация получилась обратная:
Сравнивали на реальной нагрузке (40-50 разных сайтов на php) nginx + php-fpm + xcache и nginx + apache + mod_php + xcache, настройки пулов worker в apache и php-fpm одинаковые.
Да при старте php-fpm занимает в памяти меньше места, но через некоторое время догоняет и обгоняет apache. У apache больше памяти остается разделяемой между процессами.
Разница в использовании памяти не велика (в пределах 7-10%), но она сесть.
Производительность php-fpm по сравнению с apache + mod_php меряли на синтетических тестах (ab), на том же наборе сайтов — php_fpm на 2-4% быстрее apache. Причем на apache стоит mod_security, который явно не ускоряет процесс…
С учетом того что часть сайтов не наши и необходимо для них конвертировать rewrite apache в nginx — остались на связке nginx + apache
Сравнивали на реальной нагрузке (40-50 разных сайтов на php) nginx + php-fpm + xcache и nginx + apache + mod_php + xcache, настройки пулов worker в apache и php-fpm одинаковые.
Да при старте php-fpm занимает в памяти меньше места, но через некоторое время догоняет и обгоняет apache. У apache больше памяти остается разделяемой между процессами.
Разница в использовании памяти не велика (в пределах 7-10%), но она сесть.
Производительность php-fpm по сравнению с apache + mod_php меряли на синтетических тестах (ab), на том же наборе сайтов — php_fpm на 2-4% быстрее apache. Причем на apache стоит mod_security, который явно не ускоряет процесс…
С учетом того что часть сайтов не наши и необходимо для них конвертировать rewrite apache в nginx — остались на связке nginx + apache
Не разбирался как сделано в MPM-ITK, но с php-fpm делается примерно так: для каждого, утрируя, сайта (а в принципе вплоть до отдельных location nginx с одной стороны, и групп сайтов с другой) поднимаем свой сокет (сетевой на отдельном порту или unix) и для него организуем пул воркеров. Этот пул может запускаться от произвольного пользователя и группы, использовать chroot и chdir, использовать индивидуальные настройки php, в общем кастомизироваться. Есть некоторый оверхид в виде невозможности (кажется) динамически сбалансировать нагрузку в целом, то есть для каждого сайта (пула) должен быть минимум один воркер, даже если на этот сайт раз в неделю заходят, а максимальное количество воркеров которые могут подняться можно только (кажется) посчитать, сложив максимальное количество воркеров для каждого пула, но для варианта типа «основной сайт + личные поделки» вполне приемлемо.
Хорошо, то хорошо. Только mod_rpaf совсем больной.
Вместо него лучше использовать mod_extract_forwarded который тащит за собой еще mod_proxy.
Вместо него лучше использовать mod_extract_forwarded который тащит за собой еще mod_proxy.
А чем болен mod_rpaf, простите за ламерство?
Я в курсе, что в комплекте идет конфиг с ошибкой — но вроде бы одну строчку поправить не проблема…
Я в курсе, что в комплекте идет конфиг с ошибкой — но вроде бы одну строчку поправить не проблема…
В том, что он как минимум неверно возвращает X-Real-IP и X-Forwarded-For модулю mod_rewrite. Решения предлагаемые адептами rpaf умиляют своей инвалидностью — с таким успехом тогда проще уще переписывать все рулесы вручную под nginx.
Насколько я знаю баг зарепорчен разработчику, уже сто лет в обед а воз и ныне там. mod_realip и его производные больны той же детской болезнью.
Поэтому таки mod_extract_forwarded.
Насколько я знаю баг зарепорчен разработчику, уже сто лет в обед а воз и ныне там. mod_realip и его производные больны той же детской болезнью.
Поэтому таки mod_extract_forwarded.
Я бы все таки посоветовал логи не отключать.
Знаете. Я тоже согласен. Просто я решил немного диск оптимизировать.
Дело в том, что я чрезвычайно редко в них заглядываю. Так что только место на диска /var потребляют. Я подумал, что когда начнутся проблемы, я их буду снова все активировать. А на что бы вы обратили внимание, касательно логов, какие есть подводные камни?
Дело в том, что я чрезвычайно редко в них заглядываю. Так что только место на диска /var потребляют. Я подумал, что когда начнутся проблемы, я их буду снова все активировать. А на что бы вы обратили внимание, касательно логов, какие есть подводные камни?
Ситуации разные бывают, будут у Вас 500, 504 ошибки вываливаться, 1 раз из 100, это уже плохой знак.
Спасибо за старания, буду ждать продолжения.
Подход у вас системный, вот было бы интересно в вашей интерпретации рассмотреть разность в производительности чистого LAMP и nginx+php-fpm по каких-то конкретных тестах. Стало бы ясно: насколько овчинка выделки стоит.
Подход у вас системный, вот было бы интересно в вашей интерпретации рассмотреть разность в производительности чистого LAMP и nginx+php-fpm по каких-то конкретных тестах. Стало бы ясно: насколько овчинка выделки стоит.
Чистый LAMP проигрывает и LEAMP, и LEMP в реальных условиях (то есть когда на один php-скрипт куча статики), а вот между LEAMP и LEMP особой разницы не заметил, кроме повышенного потребления оперативки в первом случае.
А что в данном случае обозначает E в аббревиатуре LEAMP/LEMP? LNMP — знаю, про LEAMP/LEMP не подсказала даже Википедия.
Что проигрывает — я так и думал, потому что постоянно об этому слышу и потому что иначе бы никто с альтернативными веб-серверами не морочился. Но вот интересно: а насколько проигрывает в реальном проекте?
Что проигрывает — я так и думал, потому что постоянно об этому слышу и потому что иначе бы никто с альтернативными веб-серверами не морочился. Но вот интересно: а насколько проигрывает в реальном проекте?
(E)ngin(e) X Не знаю насколько корректно такое сокращение, но пару раз на глаза попалось и понравилось :)
Точных цифр не помню, да и железо тогда не сильно сейчас актуальное было, но в разы точно, если не на порядок. Был шокирован тормозами Apache при отдаче статики, не говоря о потреблении памяти.
Точных цифр не помню, да и железо тогда не сильно сейчас актуальное было, но в разы точно, если не на порядок. Был шокирован тормозами Apache при отдаче статики, не говоря о потреблении памяти.
Мне стало интересно. Я проведу тестирование в конце цикла статей.
Только следует учесть, что на голом php скрипте разница будет не сильно заметна, нужно эмулировать не просто GET /index.php, а и запрос всех файлов стилей, JS и картинок обычно идущих к нему в нагрузку, пускай даже сервер (Apache или nginx) будет отвечать на них Not Modified по etag или if-modifeied-since
Не ради троллинга, а из любопытства и с целью просвещения (ведь реально могу не знать чего-то важного)…
Вопрос к автору и к опытным администраторам: какие есть критические причины, кроме привычки, для того, чтобы не использовать на продакшене Ubuntu Server вместо Debian с dotdeb?
Вопрос к автору и к опытным администраторам: какие есть критические причины, кроме привычки, для того, чтобы не использовать на продакшене Ubuntu Server вместо Debian с dotdeb?
Я использую Ubuntu Server и dotdeb :) А вообще Debian славится стабильностью софта в своих репах, а сервер ведь это не только PHP, но и куча чисто системного софта, начиная с ядра. Чисто субъективно вероятность того что с сервером будут проблемы из-за кривого, скажем, sshd пришедшего при очередном обновлении ниже в debian, чем в ubuntu.
Теоретически я с вами согласен, да. Но практически не слышал за 1,5 года и двух новостей о том, что какой-то из пакетов Ubuntu Server оказался дырявым в то время, как аналогичный дебиановский — устоял.
А dotdeb на Ubuntu Server из-за чего используете? Там ещё свежее пакеты, чем в не-LTS? Когда-то там вроде бы был более свежий nginx, но сейчас — не слежу.
А dotdeb на Ubuntu Server из-за чего используете? Там ещё свежее пакеты, чем в не-LTS? Когда-то там вроде бы был более свежий nginx, но сейчас — не слежу.
Согласен. Поэтому и ставлю.
Дополнительный аргумент — он менее всего перегружен. К примеру, если я захочу sudo на сервере, я его поставлю, а в ubuntu он по умолчанию, равно как и многое другое, что раздражает. Я люблю чистые ОСи с минимум софта на старте.
Дополнительный аргумент — он менее всего перегружен. К примеру, если я захочу sudo на сервере, я его поставлю, а в ubuntu он по умолчанию, равно как и многое другое, что раздражает. Я люблю чистые ОСи с минимум софта на старте.
в принципе — нет, скорее наоборот:
Ubuntu LTS имеют более долгий жизненный цикл (5 лет против ~2 года у Debian)
мы в своей компании например долгое время использовали Debian, но сейчас все новые сервера — Ubuntu Server
Ubuntu LTS имеют более долгий жизненный цикл (5 лет против ~2 года у Debian)
мы в своей компании например долгое время использовали Debian, но сейчас все новые сервера — Ubuntu Server
worker_processes — рабочих процессов поставил по количеству ядер / 2Почему пополам? Обычно рекомендуют по количеству ядер.
DeflateCompressionLevel 1Сжимайте nginx'ом, а не апачем.
почему бы не 9-ть?Потому что ресурсов потребляет больше, чем 5. А выигрыша по размеру практически нет.
> Почему пополам?
Рекомендуют да, но на самом деле пока и так справляется.
> Сжимайте nginx'ом, а не апачем.
Аааа. Вот с этим не соглашусь. Это особый феншуй. Сжатие apache позволяет меньше данных передавать через сеть между бэкендом и фронтендом, соответственно тратить меньше ресурсов на операцию копирования памяти. Почитайте, везде советуют сжимать на бэкендах сразу же.
Рекомендуют да, но на самом деле пока и так справляется.
> Сжимайте nginx'ом, а не апачем.
Аааа. Вот с этим не соглашусь. Это особый феншуй. Сжатие apache позволяет меньше данных передавать через сеть между бэкендом и фронтендом, соответственно тратить меньше ресурсов на операцию копирования памяти. Почитайте, везде советуют сжимать на бэкендах сразу же.
Почитайте, везде советуют сжимать на бэкендах сразу же.Хочу ссылки. Меняю вот на эти:
blog.stuartherbert.com/php/2008/04/19/using-mpm-itk-to-secure-a-shared-server/
blog.stuartherbert.com/php/2008/03/20/using-mpm-peruser-to-secure-a-shared-server/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Настройка Nginx + LAMP сервера в домашних условиях. Часть 1: Настройка frontend — backend