Comments 50
Извините, я правильно понял что единственная причина того что apache все ещё у Вас используется — это возможность редактирования htaccess пользователями?

Просто за вычетом этой возможности, nginx давно уже сам с php взаимодействует
Здравствуйте!

Apache используется, чтобы была возможность редактировать .htaccess. Это позволяет клиентам самостоятельно настраивать поведение веб-сервера.
Здравствуйте!

Спасибо за вопрос. Да, всё верно: чтобы редактировать .htaccess. Так как это важно для наших клиентов.

Я уже сколько времени пытаюсь выяснить что ещё может дать связка nginx и apache, кроме .htaccess, чтобы имелся смысл тащить apache. Сам от shared-хостинга ушёл и взял дешёвую VDS, которой не достаточно. Раз свой сервер, то проще нужные правила .htaccess в настроках виртуального хоста прописать.
Так. О чём это я? А!!! Кто знает ещё причины необходимости использования Apache?

Многие плагины для того же wordpress все так же работают посредством htaccess + многие cms не дают адекватного конфига для Nginx, а сразу отвечают на такой запрос — ставьте apache2… Л — лень.

Да, тот же Битрикс (если сайт чуть сложнее чем одностраничная визитка) удобнее держать на связке nginx + apache. Кроме того если "не жалеть заварки" то особой выгоды от использования только nginx нет. Расшифрую — если оперативки хоть попой ешь то связка nginx + apache ничуть не "медленне" чем nginx + php-fpm если всё грамотно настроить. Если же с оперативной беда, то да прожорливый до неё apache стоит исключить.

На самом деле на бакенде apache+mod_php кушают примерно столько же, сколько php-fpm при одинаково настроенных пулах. Так что выбор того или другого бакенда — вопрос больше личных предпочтений.
на самом деле смысл не в озу, а смысл в самом Nginx, при тех же настройках для бекенда, wordpress на nginx Работает быстрее

как у вас я хз

Где "быстрее"? В чём "быстрее" ?


nginx больше одновременных соединений удержит чем nginx+apache, но "быстрее" чтобы была заметная разница не будет !

Скорей всего за счет прямой отдачи статики. С апачем в зависимости от типа многопроцессной работы — prefork например — может требоваться дополнительное время для запуска нового воркера апача, даже если отдается статика. Причем процесс апача включает в себя и рнр, так что время на запуск требует дополнительных миллисекунд.

Nginx при правильной настройке просто отдает статику, что быстрее всего.

Вы описали prefork + mod_php а если prefork + mod_fcgid и не нужно запускать процесс на каждый запрос а в связке nginx+apache — статику отдаёт тоже nginx тогда разве будет столь уж ЗНАЧИТЕЛЬНАЯ разница в "быстроте" сайта?

я уже давно ушел от апача в сторону nginx, поэтому не следил за особенностями настройки уже примерно 10 лет. Скорей всего будет достаточно быстро.

Но в любом случае довольно часто рекомендуется прикрывать апач чем-то типа nginx/lighttpd чтобы бороться с медленными соединениями. У того же nginx на соединение кушаются считанные килобайты оперативной памяти, а вот апач кушает на обработку соединения побольше.
Но в любом случае довольно часто рекомендуется прикрывать апач чем-то типа nginx/lighttpd чтобы бороться с медленными соединениями.

Разумеется так — и статья про nginx+apache и я именно про это отвечал а не про голый apache.


а вот апач кушает на обработку соединения побольше.

И с этим я тоже полностью согласен и про это тоже выше писал:


"Расшифрую — если оперативки хоть попой ешь то связка nginx + apache ничуть не "медленне" чем nginx + php-fpm если всё грамотно настроить. Если же с оперативной беда, то да прожорливый до неё apache стоит исключить."


Пришли к взаимопониманию? :)

Ну на самом деле я только предположил, почему апач не с оптимальными настройками мог оказаться в отдельных сценариях чуть медленнее :))

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

Чем больше оперативы тем дороже машина а попой ешь это сколько?

Чем больше оперативы тем дороже машина

Это так но выше я писал: "если "не жалеть заварки""


а попой ешь это сколько?

Столько что хватает всем процессам в пике нагрузки и ещё файловому кэшу остаётся с горкой :)
У меня так free -h:


              total        used        free      shared  buff/cache   available
Mem:            62G        2,3G         42G        2,3G         17G         57G
Swap:            0B          0B          0B

Временами buff/cache и до 25G доходит.

Ну таким "макаром" что Apache, что php-fpm, интересно сколько будет стоить такого рода машина например на AWS

У nginx есть директива include, которая отлично справляется с этой задачей. Можно подключить конфиг и из папки проекта и даже по маске типа *.conf
На счёт горячего апдейта совсем без перезапуска не уверен, но по документации service nginx reload и так делает перезагрузку без даунтайма. В общем это тоже решаемо.


Вердикт: наличие апача не обязательно

[01:59:31 boot@hosting:~]$ service nginx reload
Failed to reload nginx.service: The name org.freedesktop.PolicyKit1 was not provided by any .service files
See system logs and 'systemctl status nginx.service' for details.


И это ещё пользователю 'boot' многое позволено.

Если вдруг мой намёк непонятен: в посте речь идет о Shared хостинге, у пользователя хостинга минимальные права, а то и вообще может не быть шелла, только FTP, а Вы про «service nginx reload»…

Намек понятен) и я согласен с аргументами. Но я скорее предполагал в своем сообщении, что перезапуск будет не от юзера, а по триггеру на изменение файла конфига, например.


Честности ради скажу что так не делал, но беглый гуглинг (по запросу nginx auto reload config) подсказывает что это возможно.


В общем я не вижу прям сильного провода держать апач. Сейчас он только из-за .htaccess

Сейчас он только из-за .htaccess

Именно! Если кто-то напишет демона для nginx, который будет перечитывать пользовательские файлы .htaccess и сразу генерировать конфиги грубо говоря в /etc/nginx/sites-conf/sitename.conf и делать релоад при валидности конфигов… Вот тогда закапыватели Апача будут правы.
Уже сколько лет пытаюсь найти вменяемый конвертер .htaccess в конфиг для nginx'a, и в большинстве случаев приходится матерится и ставить apache. Ибо проще разобраться в правилах pf чем в той портянке которую генерят плагины вордпреса.

pf придумали марсиане. Из второго слева от создателей regexp'ов канала. (с)bash

Давным-давно, когда деревья были выше, трава зеленее, а PHP выглядел далеко не так, php-fpm еще не существовал, а поэтому подружить быстрый nginx и php было очень не тривиальной задачей. Скорей всего именно поэтому и появился компромисс — статику отдавать быстрым nginx, а php дёргать из apache. Скорей всего именно из-за этого и появился эдакий бутерброд из двух слоёв хлеба.


Но недавно, к счастью, свершилось чудо!
Вышел в мир php-fpm и в новейшей версии php5.4 он был стабилизирован. Однако не все еще успели распробовать новинку… Ой, подождите, это же было в 2011 и с тех пор прошло уже 9 лет.


Возможно, нет никакой большой разницы между nginx + php-fpm и apache + mod_php, но есть значительная разница между nginx + php-fpm и nginx + apache + mod_php.

но есть значительная разница между nginx + php-fpm и nginx + apache + mod_php.

Большая разница в чём?
Число одновременных соединений первый вариант выдержит больше чем второй (ибо второй вариант быстрее всю оперативку сожрёт), но если просто "скорость" сайта то при грамотной настройке и большом запасе в оперативке никакой значительной разницы нет (грамотной это значит что вопреки всем мануалам по связке nginx+apache не отключать в apache KeepAlive а наоборот в nginx включить не только KeepAlive "наружу", но и к бекэнду — и т.д. и т.п.).
P.S.
Если реальные варианты рассматривать то лучше не nginx + apache (prefork + mod_php) а nginx + apache (prefok + mod_fcgid) — во многих cms так лучше будет в работе.

В том, что апач не бесплатный, как и proxy_pass до него, а 1 + 1 + N всегда будет больше чем просто 1 + 1? Или это не очевидно из школьного курса математики?


во многих cms так лучше будет в работе.

Это приоткрывает завесу тайны над фанатичной любовью к апачу.
Не, я понимаю, что в случае с вордпресс/друпал/битрикс и всяким прочим, че уж там те накладные расходы — три с половиной rps они и есть, зато плагины могут гадить прямо в .htaccess. Удобно же.
Но мир php состоит далеко не из одних cms, да и те как-то обходятся и уживаются с nginx.
И в связи с этим здравый смысл задаёт нам два вопроса:


  1. Зачем в принципе нужно лишнее звено в виде apache между nginx и php, если все отлично работает и так?
  2. Зачем выбирать apache вместо nginx, если nginx + php-fpm имеют примерно одинаковую скорость работы с c apache + mod_php, но nginx быстрее обрабатывает статику и ssl, а в большинстве случаев (раз уж вы начали за cms, то в подавляющем) работа сервера будет заключаться и в обработке статики в том числе.

а nginx + apache (prefok + mod_fcgid) — во многих cms так лучше будет в работе

Так чем же nginx + apache будет лучше, чем просто nginx?

1 + 1 + N всегда будет больше чем просто 1 + 1? 

А я писал что это не так? Или Вы сами с собой разговариваете? Я писал что нет "ЗНАЧИТЕЛЬНОЙ" разницы !


Так чем же nginx + apache будет лучше, чем просто nginx?

А я нигде этого и не утверждал! Странно Вы выдёргиваете фразы собеседника видимо не понимая информацию изложенную в текстовом виде :(


Я писал что "nginx + apache (prefok + mod_fcgid) — во многих cms так лучше будет в работе" чем "nginx + apache (prefok + mod_php).


Зачем выбирать apache вместо nginx

Совершенно незачем и я никому так делать не советовал. Я всего лишь отметил что apache ВМЕСТЕ с nginx имеет право на существование так как ЗАМЕТНОЙ разницы с nginx + php-fpm нет. Только это — не выдумывайте пожалуйста за меня того что я не писал.

Чего у вас так подгорает и прет в сторону apache? Ибо это слегка выглядит не очень здраво…

Да нет, же.


Блин — неужели я так плохо объясняю свою позицию? :(


Статья хостера о связке apache + nginx — и автор статьи объяснил что такой выбор обусловлен хотелками его клиентов. Ну наверное хостеру с большим кол-вом клиентов виднее как устраивать свой бизнес — разве нет ?


А набежали нескольско страдальцев суть сообщений которых — apache не нужен и пишут что с ним "значительно" хуже.


Я пишу не о том что без apache нельзя обойтись а то что бывает ситуации что с ним удобнее и о том что утверждение что связка nginx+apache ЗНАЧИТЕЛЬНО хуже чем nginx+php-fpm неверно.


Всё! Никаких "подгораний" :)

Ну если там cms с ttfb далеко за 300, то, конечно, значительной разницы не будет.

Они имеют право на существование, но кроме возможности править .htaccess на лету apache не несет дополнительной пользы.
А все сравнения apache с nginx, в которых они идут наравне это с отключенным AllowOverride, с ним же apache бегает на каждый запрос по диску в поисках этого самого .htaccess и это уже и есть та самая кардинальная разница.

То есть либо apache не нужен вообще, потому что он просто труба, в которую в одну сторону влили, из другой вылилось и он просто кушает ресурсы чтоб ничего не делать.
Либо у нас AllowOverride включен, но apache уже не очень сопоставим по производительности с nginx. И вот тут появляется та самая значительная разница.

Не хотел из-за врождённой скромности но видимо придётся :(
В профиле у меня указан мой сайт.
Битрикс "тяжёлой" редакции "Эксперт", плюс хотя по внешнему взгляду не скажешь под капотом ещё куча самописных скриптов и фич облегчающих работу с сайтом помимо всего битриксова зоопарка.
AllowOverride включён. Nginx+apache (prefork + mod_fcgid).
Пробежитесь по сайту, померяйте чекерами "скорость", TTFB и т.д.
Если после это скажете что сайт "медленный" — бросьте в меня камень :)

"Не виноватая я" — как раз за посты в этой теме получил минус 1 в карму а у "отхарбленных" выходит не видна ссылка :(


Извините не знал.


Надеюсь что сильно правил не нарушу указав прямую ссылку в сложившихся обстоятельствах:
https://www.babai.ru

хороший сайт, быстрый.
а что на нем скорость мерять — он же полупустой :)
ну не в смысле что на нем чего-то не хватает, но это тот объем когда даже фуллскан таблиц практически не играет роли в производительности.

но добавьте пару десятков тысяч статей, тегов и посмотрите как оно будет жить, когда битрикс начнет активно бегать в бд.

я согласен, что у cms и битрикса есть своя ниша и они могут работать хорошо при тонкой настройке, но взгляните на большинство интернета — это грустно и «микрооптимизациями» занимаются крайне мало людей, можно же поставить волшебный плагин для кеша чтоб всё это хотябы не умирало.

ну и плюс php это все-таки не только cms, у меня yii2 под нагрузкой отдает страницу за 10-15мс без вообще какого-либо кеша бд, прикрутить пусь редис и это будет 3-5мс, на фоне которых еще и апач добавит своих.
и это будет уже заметно.
И снова в комментариях полно веганов, не понимающих зачем нужен apache, которым обязательно необходимо всему миру сообщить что они 10 лет уже не едят мясо не пользуются apache.
А те кто пользуются — просто злые из-за мяса тормозящих под apache сайтов.

Вы бы запустили свой хостинг, чисто с nginx + php-fpm. И объясняли бы каждому клиенту, что он просто тупой раз не может обойтись без apache.
У себя использую уже несколько лет исключительно dedicated схему с персональными апачами для каждого пользователя даже на самых минимальных тарифах. До этого поначалу также был один общий apache itk и самый главный недостаток это когда у кого-то из клиентов случается какой-то «затык» — приходит запрос, php что-то долго думает, либо вообще запрашивает что-то из вне, а этот внешний источник «лежит», процесс зависает. Следующий запрос обрабатывает следующий свободный процесс и вродебы более-менее работает до тех пор пока на тот проблемный зависающий скрипт не приходит запросов больше, чем maxrequestworkers. В итоге зависшими оказываются все процессы apache и новые запросы, даже если они от других клиентов и беспроблемные быстрые, они просто стоят в очереди и все сайты на сервере оказываются зависшими.

Ну и память opcache была естественно занята в основном скриптами тех сайтов, где больше траффика. А клиенты с 2 запросами в день получается были ущемлены и у их скриптов почти каждый раз выходит «холодный старт».

Поэтому сейчас только выделенные процессы каждому с его личной памятью.
Плюс аналогично сделано с mysql. Т.к. одна общая это также плохо как shared apache.

Однако на данный момент сделано чтобы было: 1 пользователь = 1 ветка apache/mod_php с одной версией php. Все прозрачно и понятно, 1 пользователь = какое-то макс число памяти и процессов. Кому нужно больше — берет тариф выше с бо́льшими лимитами и на другом сервере с меньшим числом соседей.

Но. Изредка возникают вопросы у пользователей, которые в пределах одного аккаунта хотят разные версии php для разных сайтов. Сейчас просто делается ему новый аккаунт под новую версию php. Опять же, логично, пользователь хочет еще один «блок» из памяти и числа процессов, извольте доплатить +1 тариф.

Да, можно было бы сделать как у вас: 1 пользователь = до 8 пар (число версий php) apache/mod_php под разные версии, но как тогда ограничивать память и процессы, но чтоб все по справедливости было? А не так что одни сайты под одной веткой занимали чего-то больше и ограничивали другие под другой. Либо без ограничения, но тогда потенциально пользователь сможет 8-кратно превысить лимиты своего тарифа.

image

По вашей картинке выходит, что у user 2 его единственному сайту доступно все по максимуму в пределах его тарифа. А у user 1 как? Apache 7.1 и 7.2 делят пополам макс. предел по процессам и памяти? Или не пополам, что один из сайтов может перетянуть все одеяло на себя и клиент не будет понимать почему второй сайт хуже работает? Т.е. теоретически если человек добавит 8 сайтов и все под разными версиями php, то каждый из них будет по сути в 8 раз более ограничен, чем если бы все сайты были под какой-то одной версией php. В общем не понятно как у вас реализована дележка числа процессов и памяти между разными апачами в пределах одного аккаунта.
А у user 1 как? Apache 7.1 и 7.2 делят пополам макс. предел по процессам и памяти? Или не пополам, что один из сайтов может перетянуть все одеяло на себя и клиент не будет понимать почему второй сайт хуже работает? Т.е. теоретически если человек добавит 8 сайтов и все под разными версиями php, то каждый из них будет по сути в 8 раз более ограничен, чем если бы все сайты были под какой-то одной версией php. В общем не понятно как у вас реализована дележка числа процессов и памяти между разными апачами в пределах одного аккаунта.


Здравствуйте!

Один мастер-процесс Apache2 с воркерами обслуживает все сайты одной версии PHP одного клиента. Каждый мастер-процесс имеет одинаковое количество ресурсов (ресурсы не режутся на количество сайтов). Получается, у user 1: сайт на Apache 7.1 имеет свой мастер-процесс, Apache 7.2 — свой. Таким образом, один сайт на PHP 7.1 будет иметь столько же ресурсов, сколько и два сайта на PHP 7.2 для одного клиента.

Ответили ли мы на Ваш вопрос?
Ну то есть по тарифу пользователя конфиги апача прописаны скажем на 10 процессов максимум и соотв. php под скажем 1гб памяти. Далее пользователь добавляет сколько-то сайтов и задействует все 8 версий php. Т.е. суммарно уже не 10, а 80 процессов, не 1, а 8гб памяти в его распоряжении. Так выходит? Подозреваю что нет и глобально весь пользователь всеж как-то урезается до тех же тарифных 10 процессов и 1гб. А следовательно сайты на одной из восьми веток довольствуются лишь 1/8 от возможного в подобной ситуации.
Да, выходит именно так, как Вы сказали. Если клиент задействует 1 версию PHP, то получит 1 ресурс; если две версии, то в 2 раза больше ресурсов. Например, пользователь хочет перевести свой сайт на другую версию PHP. В таком случае для пользователя это пройдет без проблем с нехваткой ресурсов. Когда клиенту мало ресурсов одной версии PHP под сайт (например, клиент хочет разместить много сайтов с большой нагрузкой), то чаще всего ему нужен отдельный сервер.

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

Может стоило задуматься о написании модуля nginx для интерпретации htaccess как часть его конфига.

Вы понимаете суть? Если сделать чтоб nginx делал тот же самое, что и apache, то он уже не будет таким быстрым.
Аналогично можно вместо .htaccess все правила в конфиг apache записывать и чтоб он считывался только при перезапуске, а не при каждом запросе. И тогда можно allowoverride выключить — один из самых замедляющих апач нюансов (поиск и чтение .htaccess'ов при каждом запросе).
Но как этим будут управлять пользователи?
Или по вашей схеме — исправит чел что-то в .htaccess своем и как nginx должен будет узнать об этом? Только перечитав этот файл. Но если он начнет также как апач искать, читать и выполнять все .htaccess'ы, то он точно также станет медленней работать. Где вообще логика?
Никто вроде не мешает использовать связку inotify + epoll чтобы не перечитывать соответствующие файлы при каждом последующем запросе. Просто на Apache это натягивается аки сова на глобус в силу его внутреннего устройства, поэтому там такое вряд ли когда реализуют.
Согласны, пофантазировать с inotify epoll — любопытно!

.htaccess можно разместить в любом каталоге любого сайта. Сложно представить стабильную рекурсивную работу inotify с несколькими терабайтами данных при 80 млн занятых inode. А если демон умрет и какие-то события будут пропущены? В конечном итоге, нас интересует не столько красивое, сколько стабильное решение, которое не создаст неудобств и подойдет большинству пользователей.

По логике схемы, мы видим, что требуется делать Nginx reload при каждом изменении любого файла, с перечитыванием всех файлов .htaccess на всем сервере или где должны храниться временные данные.

Представить несложно. Трекинг, скажем, миллиона inotify дескрипторов — вполне реальная штука.
Демон умрёт и пропустит события? Какой демон? Разгребанием должен заниматься тот же nginx, ну вот умер он у вас по какой-то причине, вы его перезапустили, он заново начинает эти файлы отслеживать. И что вы при этом могли пропустить логически? Ничего.
Ну и при грамотном подходе reload всей конфигурации делать незачем — делать частичный для какого-то логически независимого кусочка не rocket science.
В общем нет в таком варианте ничего нереального, просто писать придётся много, а никому пока что не нужно оно.

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

Простите, а с какого момента контейнеры стали автоматически означать ограничения в ресурсах, в частности оперативной памяти? Namespaces это одно, cgroups это другое и они совершенно ортогональны друг другу. Или я как-то не так понял вашу мысль?
Здравствуйте!
Спасибо за Ваш комментарий и вопрос.

Попробуем ответить так:
Какой смысл использования контейнеров, если нет контроля за ресурсами? В свободе настройки конфигурации и гарантированного предоставления ресурсов? Кажется, в таком случае лучше подходит схема dedicated, она менее избыточна.

Сравним контейнерную реализацию с shared-схемой. Например, у нас есть 10 клиентов и 10 Гб оперативной памяти на сервере. Мы гарантированно дали каждому по 1 Гб памяти. Вроде всё честно! Но в какой-то момент у одного клиента появилась нагрузка на 2 Гб памяти, и часть пользователей не смогла добраться до его сайта. А в shared-схеме у каждого из 10 пользователей есть доступ к 3 Гб памяти из 10 Гб памяти, но в режиме конкуренции. То есть каждый сайт может использовать много ресурсов в один момент времени. Когда конкуренция начинает негативно влиять на работу сайтов клиента или работу других пользователей, то сервер разгружается и пользователь получает столько ресурсов, сколько ему нужно, при этом имея разумные ограничения для обеспечения работы сайтов.

Контейнеры это не только и не столько про нарезание ресурсов, сколько про изоляцию, удобство администрирования и собранный под конкретный проект окружение. В мире огромное количество мест, где ресурсы не ограничиваются совершенно, и при этом запущена целая прорва контейнеров.

Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

25 June 2006

Location

Россия

Employees

101–200 employees

Registered

11 August 2011