Комментарии 50
Просто за вычетом этой возможности, nginx давно уже сам с php взаимодействует
Спасибо за вопрос. Да, всё верно: чтобы редактировать .htaccess. Так как это важно для наших клиентов.
Я уже сколько времени пытаюсь выяснить что ещё может дать связка nginx и apache, кроме .htaccess, чтобы имелся смысл тащить apache. Сам от shared-хостинга ушёл и взял дешёвую VDS, которой не достаточно. Раз свой сервер, то проще нужные правила .htaccess в настроках виртуального хоста прописать.
Так. О чём это я? А!!! Кто знает ещё причины необходимости использования Apache?
Да, тот же Битрикс (если сайт чуть сложнее чем одностраничная визитка) удобнее держать на связке nginx + apache. Кроме того если "не жалеть заварки" то особой выгоды от использования только nginx нет. Расшифрую — если оперативки хоть попой ешь то связка nginx + apache ничуть не "медленне" чем nginx + php-fpm если всё грамотно настроить. Если же с оперативной беда, то да прожорливый до неё apache стоит исключить.
как у вас я хз
Где "быстрее"? В чём "быстрее" ?
nginx больше одновременных соединений удержит чем nginx+apache, но "быстрее" чтобы была заметная разница не будет !
Nginx при правильной настройке просто отдает статику, что быстрее всего.
Вы описали prefork + mod_php а если prefork + mod_fcgid и не нужно запускать процесс на каждый запрос а в связке nginx+apache — статику отдаёт тоже nginx тогда разве будет столь уж ЗНАЧИТЕЛЬНАЯ разница в "быстроте" сайта?
Но в любом случае довольно часто рекомендуется прикрывать апач чем-то типа 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 доходит.
У 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 и делать релоад при валидности конфигов… Вот тогда закапыватели Апача будут правы.
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.
И в связи с этим здравый смысл задаёт нам два вопроса:
- Зачем в принципе нужно лишнее звено в виде apache между nginx и php, если все отлично работает и так?
- Зачем выбирать 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 + nginx — и автор статьи объяснил что такой выбор обусловлен хотелками его клиентов. Ну наверное хостеру с большим кол-вом клиентов виднее как устраивать свой бизнес — разве нет ?
А набежали нескольско страдальцев суть сообщений которых — apache не нужен и пишут что с ним "значительно" хуже.
Я пишу не о том что без apache нельзя обойтись а то что бывает ситуации что с ним удобнее и о том что утверждение что связка nginx+apache ЗНАЧИТЕЛЬНО хуже чем nginx+php-fpm неверно.
Всё! Никаких "подгораний" :)
Они имеют право на существование, но кроме возможности править .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мс, на фоне которых еще и апач добавит своих.
и это будет уже заметно.
А те кто пользуются — просто злые из-за
Вы бы запустили свой хостинг, чисто с nginx + php-fpm. И объясняли бы каждому клиенту, что он просто тупой раз не может обойтись без apache.
Ну и память opcache была естественно занята в основном скриптами тех сайтов, где больше траффика. А клиенты с 2 запросами в день получается были ущемлены и у их скриптов почти каждый раз выходит «холодный старт».
Поэтому сейчас только выделенные процессы каждому с его личной памятью.
Плюс аналогично сделано с mysql. Т.к. одна общая это также плохо как shared apache.
Однако на данный момент сделано чтобы было: 1 пользователь = 1 ветка apache/mod_php с одной версией php. Все прозрачно и понятно, 1 пользователь = какое-то макс число памяти и процессов. Кому нужно больше — берет тариф выше с бо́льшими лимитами и на другом сервере с меньшим числом соседей.
Но. Изредка возникают вопросы у пользователей, которые в пределах одного аккаунта хотят разные версии php для разных сайтов. Сейчас просто делается ему новый аккаунт под новую версию php. Опять же, логично, пользователь хочет еще один «блок» из памяти и числа процессов, извольте доплатить +1 тариф.
Да, можно было бы сделать как у вас: 1 пользователь = до 8 пар (число версий php) apache/mod_php под разные версии, но как тогда ограничивать память и процессы, но чтоб все по справедливости было? А не так что одни сайты под одной веткой занимали чего-то больше и ограничивали другие под другой. Либо без ограничения, но тогда потенциально пользователь сможет 8-кратно превысить лимиты своего тарифа.
По вашей картинке выходит, что у 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 для одного клиента.
Ответили ли мы на Ваш вопрос?
У нас есть тарифы с выделенными серверами, где у пользователя ограничены системные права (так же, как и на предыдущих тарифах), но работает админка в панели со всеми функциями управления сайтами, которые доступны и на других тарифах. Есть и тариф, где пользователю дается Dedicated с root правами и ipmi, но уже без админки.
Может стоило задуматься о написании модуля nginx для интерпретации htaccess как часть его конфига.
Аналогично можно вместо .htaccess все правила в конфиг apache записывать и чтоб он считывался только при перезапуске, а не при каждом запросе. И тогда можно allowoverride выключить — один из самых замедляющих апач нюансов (поиск и чтение .htaccess'ов при каждом запросе).
Но как этим будут управлять пользователи?
Или по вашей схеме — исправит чел что-то в .htaccess своем и как nginx должен будет узнать об этом? Только перечитав этот файл. Но если он начнет также как апач искать, читать и выполнять все .htaccess'ы, то он точно также станет медленней работать. Где вообще логика?
.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 Гб памяти, но в режиме конкуренции. То есть каждый сайт может использовать много ресурсов в один момент времени. Когда конкуренция начинает негативно влиять на работу сайтов клиента или работу других пользователей, то сервер разгружается и пользователь получает столько ресурсов, сколько ему нужно, при этом имея разумные ограничения для обеспечения работы сайтов.
Apache & Nginx. Связаны одной цепью