Apache & Nginx. Связаны одной цепью +5



Как реализована связка Apache & Nginx в Timeweb

Для многих компаний Nginx + Apache + PHP — очень типовая и распространенная связка, и Timeweb здесь не стал исключением. Однако разобраться, как именно она реализована, может быть любопытно и полезно.

image

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

Основные настройки Apache выполняются в конфигурационных файлах самого Apache, а настройки для клиентских сайтов происходят через файл .htaccess. .htaccess — конфигурационный файл, в котором клиент может самостоятельно настроить правила и поведение веб-сервера. Такая настройка будет относиться конкретно к его сайту. Например, благодаря функционалу Apache пользователи могут менять режим работы в рамках одной версии PHP с mod_php на mod_cgi; можно настраивать редиректы, оптимизацию для SEO, удобный URL, некоторые лимиты для PHP.

Nginx используется как прокси-сервер для перенаправления трафика на Apache и как веб-сервер для отдачи статического контента. Также для Nginx мы разработали модули безопасности, которые позволяют защитить данные наших пользователей, например, разделить права доступа.

Представим, что какой-то пользователь заходит на сайт нашего клиента. Сначала пользователь попадает на Nginx, который отдает статический контент. Это происходит мгновенно. Затем, когда дело доходит до загрузки PHP, Nginx перенаправляет запрос на Apache. И Apache совместно с PHP уже генерирует динамический контент.

Особенности связки Apache & Nginx в Timeweb


На нашем виртуальном хостинге реализованы 2 основные схемы работы Apache & Nginx: Shared и Dedicated.

Схема Shared

Эта схема используется для большинства пользователей. Ее отличает простота и ресурсоемкость: Shared-схема использует меньше ресурсов, поэтому и ее тариф дешевле. Согласно данной схеме на сервере запущен один Nginx, который позволяет обслуживать все пользовательские запросы, и несколько экземпляров Apache.

Схема Shared совершенствовалась долгое время: постепенно мы исправляли недочеты. Удобно, что ее можно сделать без необходимости дорабатывать исходный код.


схема Shared

Схема Dedicated

Dedicated требует больше ресурсов, поэтому ее тариф дороже для клиентов. В Dedicated-схеме для каждого клиента поднимается свой, отдельный Apache. Ресурсы здесь резервируются под клиента, они выделяются эксклюзивно. Как это работает: на сервере есть несколько версий PHP. Мы поддерживаем версии 5.3, 5.4, 5.6, 7.1, 7.2, 7.3, 7.4. Так, для каждой версии PHP запускается свой Apache.


схема Dedicated

Safe zone. Настройка зон в Nginx


Ранее для Nginx мы использовали много зон разделяемой памяти (zone) — один блок server на один домен. Такая настройка требует большого количества ресурсов, так как для каждого сайта создается отдельная зона. Однако в настройках Nginx большинство сайтов однотипные, поэтому их удается поместить в одну зону благодаря использованию директив map в модуле ngx_http_map_module, которые позволяют задать соответствия. Например, у нас есть шаблон зоны, в которую мы должны поставлять переменные: путь к сайту, версию PHP, пользователя. Таким образом, ускорилось перечитывание конфигурации Nginx, то есть релоад.

Подобная конфигурация сильно сэкономила ресурсы оперативной памяти и ускорила работу Nginx.

Reload не пройдет!


В Shared-схеме мы избавились от необходимости перезагрузки (релоада) Apache при изменениях в настройках сайтов. Ранее, когда один клиент хотел добавить домен или поменять версию PHP, требовался обязательный релоад Apache, что приводило к задержкам в ответах и негативно сказывалось на производительности сайтов.

Мы избавились от релоадов путем создания динамических конфигураций. Благодаря mpm-itk (модулю Apache), каждый процесс выполняется от отдельного пользователя, что повышает уровень безопасности. Такой способ позволяет передавать из Nginx в Apache2 данные о пользователе и его document_root. Таким образом, Apache не содержит в себе конфигурации сайтов, он получает их динамически, и релоады больше не требуются.


Конфигурация схемы Shared

А как же Docker?


Многие компании перешли на систему, основанную на контейнерах. Timeweb сейчас рассматривает возможность такого перехода. Безусловно, в каждом решении можно найти плюсы и минусы.

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

Timeweb обеспечивает работу около 500 000 сайтов. Мы несем большую ответственность и не вносим мгновенные, неоправданные изменения в сложную архитектуру. Связка Apache & Nginx надежна и проверена временем. Мы, в свою очередь, стараемся достичь максимальной производительности благодаря уникальным конфигурациям.

Для качественной и быстрой работы большого количества сайтов требуется использовать шаблонную и динамическую конфигурацию Apache и Nginx. Она позволяет просто и быстро администрировать большое число однотипных серверов.




Комментарии (49):

  1. lleo_aha
    /#21845442 / +7

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

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

    • rudinandrey
      /#21845706 / +4

      я вот тоже думаю, зачем здесь Apache?

      • /#21845854

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

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

    • /#21845830

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

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

    • FSA
      /#21845870

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

      • Jammarra
        /#21847842

        Мод секюр иногда под него бывают специфичные правила.

    • denaspireone
      /#21845888

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

      • suffix_ixbt
        /#21846024 / -2

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

        • /#21846398

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

          • denaspireone
            /#21846634

            на самом деле смысл не в озу, а смысл в самом Nginx, при тех же настройках для бекенда, wordpress на nginx Работает быстрее

            как у вас я хз

            • suffix_ixbt
              /#21846762 / -1

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


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

              • remzalp
                /#21847438

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

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

                • suffix_ixbt
                  /#21847490

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

                  • remzalp
                    /#21847552

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

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

                    • suffix_ixbt
                      /#21847578

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

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


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

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


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


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

                      • remzalp
                        /#21847582

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

        • NiceDay
          /#21846948

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

          • suffix_ixbt
            /#21847128

            Это уже другой, совсем не связанный с обсуждаемой темой вопрос.

        • /#21848084 / +1

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

          • suffix_ixbt
            /#21848136

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

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


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

            Столько что хватает всем процессам в пике нагрузки и ещё файловому кэшу остаётся с горкой :)
            У меня так 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 доходит.

            • /#21848500

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

    • vmkazakoff
      /#21848128

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


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

      • crlam0
        /#21850098

        [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»…

        • vmkazakoff
          /#21850168

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


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


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

          • crlam0
            /#21855444

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

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

  2. NiceDay
    /#21846622 / +2

    Давным-давно, когда деревья были выше, трава зеленее, а 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.

    • suffix_ixbt
      /#21846756

      но есть значительная разница между 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 так лучше будет в работе.

      • NiceDay
        /#21846944 / +1

        В том, что апач не бесплатный, как и 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?

        • suffix_ixbt
          /#21847126

          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 нет. Только это — не выдумывайте пожалуйста за меня того что я не писал.

          • denaspireone
            /#21847312

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

            • suffix_ixbt
              /#21847326 / +1

              Да нет, же.


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


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


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


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


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

          • NiceDay
            /#21849764 / +1

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

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

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

            • suffix_ixbt
              /#21849814

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

              • NiceDay
                /#21850026

                Какой из этих 0?
                image

                • suffix_ixbt
                  /#21850038

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


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


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

                  • NiceDay
                    /#21850314

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

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

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

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

  3. NotSlow
    /#21847806

    И снова в комментариях полно веганов, не понимающих зачем нужен apache, которым обязательно необходимо всему миру сообщить что они 10 лет уже не едят мясо не пользуются apache.
    А те кто пользуются — просто злые из-за мяса тормозящих под apache сайтов.

    Вы бы запустили свой хостинг, чисто с nginx + php-fpm. И объясняли бы каждому клиенту, что он просто тупой раз не может обойтись без apache.

  4. NotSlow
    /#21848094

    У себя использую уже несколько лет исключительно 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. В общем не понятно как у вас реализована дележка числа процессов и памяти между разными апачами в пределах одного аккаунта.

    • /#21849370

      А у 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 для одного клиента.

      Ответили ли мы на Ваш вопрос?

      • NotSlow
        /#21849806

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

        • /#21852942

          Да, выходит именно так, как Вы сказали. Если клиент задействует 1 версию PHP, то получит 1 ресурс; если две версии, то в 2 раза больше ресурсов. Например, пользователь хочет перевести свой сайт на другую версию PHP. В таком случае для пользователя это пройдет без проблем с нехваткой ресурсов. Когда клиенту мало ресурсов одной версии PHP под сайт (например, клиент хочет разместить много сайтов с большой нагрузкой), то чаще всего ему нужен отдельный сервер.

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

  5. /#21848130

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

    • NotSlow
      /#21848194

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

      • hogstaberg
        /#21848528 / +1

        Никто вроде не мешает использовать связку inotify + epoll чтобы не перечитывать соответствующие файлы при каждом последующем запросе. Просто на Apache это натягивается аки сова на глобус в силу его внутреннего устройства, поэтому там такое вряд ли когда реализуют.

        • /#21849364

          Согласны, пофантазировать с inotify epoll — любопытно!

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

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

          • hogstaberg
            /#21849940

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

  6. hogstaberg
    /#21848556 / +1

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

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

    • /#21849354

      Здравствуйте!
      Спасибо за Ваш комментарий и вопрос.

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

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

      • hogstaberg
        /#21849972

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