Apache vs Nginx

Введение


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

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

Общий обзор


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

Apache


Apache HTTP Server был разработан Робертом Маккулом в 1995 году, а с 1999 года разрабатывается под управлением Apache Software Foundation — фонда развития программного обеспечения Apache. Так как HTTP сервер это первый и самый популярный проект фонда его обычно называют просто Apache.

Веб-север Apache был самым популярным веб-сервером в интернете с 1996 года. Благодаря его популярности у Apache сильная документация и интеграция со сторонним софтом.

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

Nginx


В 2002 году Игорь Сысоев начал работу над Nginx для того чтобы решить проблему C10K — требование к ПО работать с 10 тысячами одновременных соединений. Первый публичный релиз был выпущен в 2004 году, поставленная цель была достигнута благодаря асинхронной event-driven архитектуре.

Nginx начал набирать популярность с момента релиза благодаря своей легковесности (light-weight resource utilization) и возможности легко масштабироваться на минимальном железе. Nginx превосходен при отдаче статического контента и спроектирован так, чтобы передавать динамические запросы другому ПО предназначенному для их обработки.

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

Архитектура обработки соединений


Одно из самых существенных отличий между Apache и Nginx состоит в том как они обрабатывают соединения и отвечают на различные виды трафика.

Apache


Apache предоставляет несколько модулей мультипроцессинга (multi-processing modules, MPM), которые отвечают за то как запрос клиента будет обработан. Это позволет администраторам определять политику обработки соединений. Ниже представлен список MPM-модулей Apache:

  • mpm_prefork — этот модуль создает по одному процессу с одним потоком на каждый запрос. Каждый процесс может обрабатывать только одно соединение в один момент времени. Пока число запросов меньше числа процессов этот MPM работает очень быстро. Однако производительность быстро падает когда число запросов начинает превосходить число процессов, поэтому в большинстве случаев это не самый лучший выбор. Каждый процесс потребляет значительный объем RAM, поэтому этот MPM сложно поддается масштабированию. Но он может быть использован вместе с компонентами, которые не созданы для работы в многопоточной среде. Например, PHP не является потокобезопасным, поэтому этот MPM рекомендуется использовать как безопасный метод работы с mod_php.
  • mpm_worker — этот модуль создает процессы, каждый из которых может управлять несколькими потоками. Каждый поток может обрабтывать одно соединение. Потоки значительно более эффективны чем процессы, что означает что mpm_worker масштабируется значительно лучше чем mpm_prefork. Так как потоков больше чем процессов это означает, что новое соединение может быть сразу обработано свободным потоком, а не ждать пока освободится процесс.
  • mpm_event — этот модуль похож на mpm_worker, но оптимизрован под работу с keep-alive соединениями. Когда используется mpm_worker соединение будет удерживать поток вне зависимости от того активное это соединение или keep-alive. Mpm_event выделяет отдельные потоки для keep-alive соединений и отдельные потоки для активных соединений. Это позволяет модулю не погрязнуть в keep-alive соединениях, что необходимо для быстрой работы. Этот модуль был отмечен как стабильный в Apache версии 2.4.

Как вы можете видеть Apache предлагает гибкие возможности для выбора различных алгоритмов обработки соединений и запросов.

Nginx


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

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

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

Этот подход к обработке соединений позволяет Nginx'у невероятно масштабироваться при ограниченных ресурсах. Поскольку сервер однопоточный и он не создает процессы под каждое соединение, использование памяти и CPU относительно равномерно, даже при высоких нагрузках.

Статический и динамический контент


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

Apache


Apache может раздавать статический контент используя стандартные file-based методы. Производительность таких операций зависит от выбранного MPM.

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

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

Nginx


Nginx не имеет возможности самостоятельно обрабатывать запросы к динамическому контенту. Для обработки запросов к PHP или другому динамическому контенту Nginx должен передать запрос внешнему процессору для исполнения, подождать пока ответ будет сгенерирован и получить его. Затем результат может быть отправлен клиенту.

Для администраторов это означает, что нужно настроить взаимодействие Nginx с таким процессором используя один из протоколов, который известен Nginx'у (http, FastCGI, SCGI, uWSGI, memcache). Это может немного усложнить процесс настройки, в особенности когда вы будете пытаться предугадать какое число соединений разрешить, так как будет использоваться дополнительное соединение с процессором на каждый пользовательский запрос.

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

Распределенная конфигурация против централизованной


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

Apache


Apache имеет опцию, которая позволяет включить конфигурирование на уровне директорий. Если эта опция включена, то Apache будет искать конфигурационные директивы в директориях с контентом в специальных скрытых файлах, которые называются .htaccess.

Так как такие конфигурационные файлы находятся в директриях с контентом, Apache вынужден при обработке каждого запроса проверять не содержит ли каждый компонент запрашиваемого пути файл .htaccess и исполнять директивы в найденных файлах. Это позволяет децентрализовать конфигурирование веб-сервера, что позволяет реализовать на уровне директорий модификацию URL'ов (URL rewrite), ограничения доступа, авторизацию и аутентификацию и даже политики кеширования.

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

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

Nginx


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

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

Так как Nginx не позволяет переопределять конфиги на уровне директорий, он может обрабатывать запросы быстрее, ведь ему достаточно сделать один directory lookup и прочитать один конфигурационный файл на каждый запрос (предполагается, что файл найден там где он должен быть по соглашению).

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

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

Интерпретация базирующаяся на файлах и URI


То как веб-сервер интерпретирует запрос и сопоставляет его с ресурсом в системе это еще одна отличительная особенность в этих двух серверах.

Apache


Apache имеет возможность интерпретировать запрос как физический ресурс в файловой системе или как URI, который требует дополнительной обработки. Первый тип запросов использует конфигурационные блоки <Directory> или <File>, второй — блоки <Location>.

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

Apache предоставляет ряд альтернатив на случай когда запрос не соответствует файлу в файловой системе. Использование блоков <Location> это метод работы с URI без отображения на файловую систему. Также возможно использовать регулярные выражения, которые позволяют задать более гибкие настройки для всей файловой системы.

Так как Apache может оперировать и c файловой системой, и с webspace, то он в основном опирается на методы работы с файловой системой. Это видно в некоторых решениях в дизайне архитектуры веб-сервера, например, в использовании файлов .htaccess для конфигурирования на уровне директорий. Документация к Apache не рекомендует использовать URI-блоки для ограничения доступа для запросов к файловой системе.

Nginx


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

Эта особенность прослеживается в том как для Nginx конструируются и интерпретируются конфигурационные файлы. В Nginx нет способа создать конфигурацию для заданной директории, вместо этого он парсит URI.
Например, основными конфигурационными блоками в Nginx являются <server> и <location>. В блоке <server> определяется хост, который будет обслуживаться, блок <location> отвечает за обработку части URI, которая идет после имени хоста и номера порта. Таким образом, запрос интерпретируется как URI, а не как путь в файловой системе.

В случае запросов к статическим файлам все запросы должны быть отображены (mapped) на путь в файловой системе. Сначала Nginx выбирает блоки server и location, которые будут использованы для обработки запроса и затем объединяет document root с URI, в соответствии с конфигурацией.

Эти подходы (интерпретация запроса как пути в файловой системе и как URI) могут показаться похожими, но тот факт что Nginx рассматривает запросы как URI, а не как пути в файловой системе позволяет ему легче справляться одновременно и с ролью веб-сервера, и с ролью прокси. Nginx конфигурируется так, чтобы отвечать на различные шаблоны запросов. Nginx не обращается к файловой системе до тех пор пока он не готов обслужить запрос, что объясняет почему он не реализует ничего похожего на файлы .htaccess.

Модули


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

Apache


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

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

Использование модулей не ограничивается лишь обработкой динамических запросов. Среди других возможностей модулей: изменение URL'ов (URL rewrite), аутентификация клиентов, защита сервера, логгирование, кеширование, сжатие, проксирование, ограничение частоты запросов, шифрование. Динамические модули могут значительно расширить функцональность ядра.

Nginx


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

Для многих пользователей по этой причине Nginx кажется менее гибким. Это особенно относится к пользователям, кто имеет мало опыта ручной сборки приложений и предпочитают использовать системы управления пакетами. Обычно разработчики дистрибутивов стремятся создать пакеты для всех часто используемых модулей, но если вам нужен какой-то нестандартный модуль вам придется собрать его из исходников самостоятельно.

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

Модули Nginx реализуют те же возможности, что и модули Apache: проксирование, сжатие данных, ограничение частоты запросов, логгирование, модификация URL'ов, гео-локация, аутентификация, шифрование, потоковое вещание, почтовые функции.

Поддержка, совместимость, экосистема и документация


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

Apache


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

Существует много инструментов и веб-проектов идущих в комплекте со средствами запуска самих себя из под Apache. Это относится как к самим проектам, так и к системам управления пакетами.

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

Nginx


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

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

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

Совместное использование Apache и Nginx


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

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

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

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

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

Заключение


Как вы можете видеть и Apache, и Nginx — это мощные, гибкие и функциональные инструменты. Для того чтобы выбрать сервер под ваши задачи необходимо определиться с требованиями к нему и провести тесты на всех возможных паттернах использования вашего приложения.

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

Комментарии (184)


  1. baldr
    25.09.2015 13:39
    +16

    А кто сейчас до сих пор выбирает Apache для использования и в каких случаях?
    По мне, единственной причиной может быть только использование какой-то CMS, которая только с ним может работать.
    Для PHP уже вполне нормально работает php-fpm и hhvm, а для всего остального есть более легковесные wsgi-сервера типа puma, gunicorn, etc…


    1. vvpoloskin
      25.09.2015 13:59
      +17

      Ну, например, если мне нужна была NTLM аутентификация для страниц сайта, nginx бы мне не подошел. Для шаред-хостинга nginx также не очень подходит. Я могу привести много различных кейсов, когда apache лучше nginx. Веб не ограничивается сотней публичных однотипных стартаперских сайтов.


      1. Ar2r
        25.09.2015 14:22
        +2

        Apache+KeepAlive+NTLM = рабочее решение.

        Но, на данный момент мне не известно есть ли рабочее решение для Nginx.


      1. Regis
        25.09.2015 14:46

        nginx прекрасно подходит для shared-хостинга в роли прокси перед апачем )


        1. erlyvideo
          25.09.2015 23:02
          +7

          собственно, покажите мне апач без nginx перед ним и я его выключу с помощью slowheaders


          1. romy4
            29.09.2015 14:24

            nginx тоже нормально падал пару лет назад от slow headers.


      1. ValdikSS
        25.09.2015 14:55
        +6

        Для шаред-хостинга nginx также не очень подходит.
        Это из-за того, что никто еще how-to по настройке nginx+uwsgi-php не написал.


        1. merlin-vrn
          25.09.2015 16:01

          Дак было же где-то на хабре, нет?


          1. ValdikSS
            25.09.2015 16:02

            Не уверен, вроде нет. По крайней мере, я ни один мануал не находил именно к php.


            1. merlin-vrn
              25.09.2015 16:05
              +3

              Да там универсально же, пишешь в ini-файле plugin=php54 — будет php 5.4, пишешь python27 — всё понятно. Как-то непоятно, почему нужен отдельный мануал именно для php.

              один тестовый виртуалхост у меня крутится с таким конфигом пользовательского uwsgi (который запускается рутовским uwsgi-tyrant):
              [uwsgi]
              plugin = php54
              php-set = date.timezone=Europe/Moscow


              1. ValdikSS
                25.09.2015 16:07

                Ну, потому что не гуглится. Вот я хочу настроить php в nginx через uwsgi, а инструкции нет.
                Я-то настрою, а другие так и продолжат fastcgi использовать.


                1. SysCat
                  25.09.2015 16:54

                  А так не пойдет?


                  1. WST
                    29.09.2015 14:28

                    Там не про PHP. Суть в том, что uWSGI отлично подходит и для обслуживания PHP, сайтов, давая при этом даже большую гибкость, чем php-fpm, практически кладя последний на лопатки по возможностям.


        1. vvpoloskin
          25.09.2015 16:34
          +5

          Это из-за того, что:

          • в nginx нельзя сделать .htaccess на уровне директории
          • в nginx нельзя сделать отдельного пользователя и группу для виртуальных хостов


          1. merlin-vrn
            25.09.2015 16:52
            +7

            в nginx нельзя сделать .htaccess на уровне директории

            в сущности на самом деле востребовано не «по конфигу на директорию», а «по конфигу на виртуалхост»

            Вообще говоря, конфиг nginx сплитится (или у вас что, все виртуалхосты в одном файле объявлены?), дальше дело техники — перечитывание конфига по inotify в помощь.

            в nginx нельзя сделать отдельного пользователя и группу для виртуальных хостов

            для статики это не нужно и так, а для скриптов — так их выполняет не сам nginx, не ему и делать отдельного пользователя и группу


            1. vvpoloskin
              26.09.2015 23:03
              +1

              1) конфиг nginx в отдельном файле будет влиять глобально. То есть, просто например, пользователь укажет слушать еще один порт, и на сервере будет открыт новый порт. Кроме того, если один пользователь напишет корявый конфиг, сервер не сможет перезагрузить все конфиги. Даже если одним шаредом пользуются 100 клиентов, вероятность невозможности перезапуска сервера большая.
              2) Далеко не всегда. В конфиге nginx можно указать алиас до статических файлов другого пользователя хостинга.


              1. PQR
                29.09.2015 12:19

                Кстати, на shared хостинге Ru-Center (http://hosting.nic.ru/) можно настраивать конфиг nginx под себя — лично пользуюсь. Как это у них технически сделано и что будет, если я напишу кривой конфиг не знаю.


                1. schors
                  29.09.2015 13:29

                  Попробуйте и расскажите. Я решил проблему сделав для хостинга «пресеты», назвав из «рецептами». Человек выбирает нужный ему. Естественно рецепт шаблонизирован и формируется согласно купленным билетам.


      1. hell0w0rd
        25.09.2015 15:08

        gist.github.com/Dygear/6291550 — вот, вроде, вариант. Правда это код на php.


      1. merlin-vrn
        25.09.2015 15:39
        +11

        Для шареда nginx подходит отлично вместе с uwsgi в режиме emperor. Даже так: он лучше подходит.

        В Apache вы имеете один mod_php и все виртуалхосты вынуждены работать с одной и той же версией php и одним конфигом. Некоторое альтернативное конфигурирование для разных хостов возможно, но ограничено. Если вы, скажем, захотите гонять не php, а python, то mod_wsgi позволит вам только одну конфигурацию virtualenv — одну на все виртуалхосты.

        В случае с nginx и uwsgi каждый виртуалхост будет выполняться в отдельном процессе, и соотстветственно может использовать разные версии php. Более того, один и тот же виртуалхост может мапиться на несколько разных процессов uwsgi, которые могут использовать разные версии php. Ещё больше, там могут быть не только разные версии php, но и разные версии python, ruby, даже mono — в общем, всё, что умеет uwsgi. Не надо и говорить, что каждый процесс может иметь свою собственную независимую конфигурацию — свой php.ini, свой virtualenv и так далее.
        (Потребление памяти из-за кучи одинаковых процессов с одним и тем же php здесь не особо выше, чем для одного процесса: uwsgi рассчитан на работу вместе с ядерным ksm.)

        В apache, чтобы скрипты виртуалхостов выполнялись от разных учётных записей, придётся ковыряться с suexec, или ставить mpm_itk (не описанный в статье). Apache с mpm_itk парсит запрос, выполняясь от рута, а потом, определив виртуалхост (например, из заголовка Host), возможно, сбрасывает привилегии. В целом это может быть брешью в безопасности. Зато, правда, есть другой плюс: с mpm_itk не только скрипты, но и обращения самого веб-сервера к файловой системе (к статическим ресурсам) будут производиться от имени учётной записи, сконфигурированной для данного виртуалхоста, что может быть удобно.

        В случае с nginx и uwsgi, веб-сервер всегда выполняется от одной и той же учётной записи для всех виртуалхостов. Поэтому доступ к статике осуществляется всегда от имени этой учётной записи (например, www-data). Зато uwsgi вместе с интерпретаторами может (и в режиме emperor-tyrant будет) выполняться от имени конечной учётной записи, которая для каждого виртуалхоста и даже приложения в рамках виртуалхоста может быть своя. Опять, это касается не только php, но и всего остального, что может запускать uwsgi.

        В принципе, у apache есть ещё mod_vhost_alias. Его можно сымитировать в nginx, но вариант apache гибче. Однако, встаёт и вопрос — кому-то оно надо?


        1. TaHKucT
          25.09.2015 16:43

          В Apache вы имеете один mod_php и все виртуалхосты вынуждены работать с одной и той же версией php и одним конфигом.
          нет


          1. baldr
            25.09.2015 16:49
            +2

            Быстрый гуглеж говорит, что решение спорное…

            www.chriswiegman.com/2011/10/fastcgi-vs-suphp-vs-cgi-vs-mod_php-dso

            The cost of the upload ability and security of suPHP is not cheap. suPHP is slow and requires quite a bit of CPU to process all the files. In addition, as it must process the file each and every time it is called, suPHP cannot use any OPCode caching such as APC or memcached resulting in even higher CPU usage by your application. If you are running on a low-end VPS or other server with an application such as WordPress this configuration can easily push you passed any CPU limits you might have whenever traffic starts to climb.


          1. merlin-vrn
            25.09.2015 17:01
            +4

            «чего только не придумают, лишь бы nginx не ставить» :)

            Я же написал: mod_php. Этот ваш suphp встроен в вебсервер? Если нет, то это решение принципиально не отличается от apache+uwsgi, fcgi, fpm и так далее.


          1. Lux_In_Tenebris
            26.09.2015 02:12

            suPHP чертовски медленный при обработке запросов. Наверное, медленее даже чем mpm_itk.


        1. schors
          26.09.2015 12:39
          -1

          Или просто вы подымаете мультиинстанс апач и не мучаете людей необычными решениями. Этому способу в обед 100 лет будет. и будет просто всё тоже самое.


        1. storm
          03.10.2015 13:20
          -1

          Если речь идет о том, чтобы на апаче крутить php, то про mod_php, suphp, suexec с их недостатками давно пора забыть. Необходимо использовать php-fpm.
          wiki.apache.org/httpd/PHP-FPM


          1. schors
            03.10.2015 14:25
            +1

            Нет никакой проблемы в mod_php. suphp и suexec нужно было забыть уже более пяти лет назад и использовать мультиинстанс апач.


            1. storm
              03.10.2015 15:30

              Ну как же нет проблемы в mod_php? Версии php, разные юзера?.. Или вы предлагаете заменить вполне стандартное и _рекомендумое_ решение какими-то костылями с «мультиинстанс апач». Дайте хоть ссылку на оф. сайт почитать где такое рекомендуется.


              1. schors
                04.10.2015 12:51

                На офсайте такое не рекомендуется. Но кстати и не отрицается. Кстати, на фосайте рекомендуется настройка apache, которая почему-то редко повторяется в дистрибутивах ОС, хотя PHP вполне обоснованно рекомендуют «костыль». Так что я к разного рода рекомендациям относился бы с осторожностью. По факту разницы нет.


      1. erlyvideo
        25.09.2015 23:02
        -1

        шаред хостинг в году, когда виртуалка стоит 5 долларов в месяц?

        Кто ими пользуется?


        1. baldr
          25.09.2015 23:03

          Те, кто пользуется бесплатным хостингом для своих страничек.


        1. VolCh
          26.09.2015 09:02
          +2

          Ещё те, кто не может или не хочет заниматься администрированием.


        1. vvpoloskin
          26.09.2015 23:06
          +2

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


          1. phoenixweiss
            27.09.2015 01:41

            Соответственно для каждой задачи хорош свой инструмент.
            До 2012-го года использовали связку nginx + apache только по той причине что она по-умолчанию у большинства шаредов предусмотрена. Потом мы стали расти, проекты стали расти, и на определенном этапе с PHP перешли на Rails, где уже работают nginx + passenger (к этому решению тоже приходили методом проб, ошибок и тестирования разных решений), а старые проекты, написанные на PHP, но которые нет вариантов переписать на рельсы, перенесли на связку nginx + php-fpm, и также, это решения оказалось удобным.
            У любого решения есть свои минусы, плюсы и своя сфера применения. Универсального убер-инструмента просто не существует, либо он слишком громоздок для небольших задач.

            Кроме того, мне всегда нравилась ситуация когда одну и ту же задачу можно решить при помощи разных подходов и инструментов. Иной раз стараюсь даже специально тестировать что-то новое и довольно часто решение если даже и не приживается, то открывает новые подходы или дает новый взгляд на старое. Так в свое время мне тоже nginx казался странноватым, неудобным и неуниверсальным, пока не поднял 4-5 серваков(где именно __так__ нужно было сделать и никак иначе) и не пришлось покопаться изрядно в конфигах, решая задачи с которыми раньше не сталкивался. Сейчас объективно для решения существующих задач альтернатив ему не вижу.


    1. pewpew
      25.09.2015 14:12

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


      1. baldr
        25.09.2015 14:20
        +5

        .htaccess, на мой взгляд, плох именно тем, что он может размазать конфигурацию по всем директориям. Имея все в одном месте — можно видеть всю конфигурацию сразу.
        Как раз роутинг бы и хотелось видеть сразу весь, потому что иначе отладка превращается в БОЛЬ.


        1. dom1n1k
          25.09.2015 16:09
          +1

          Указывать правила в каждой папке — удобно на самом деле. Разумеется, если не злоупотреблять.


        1. TaHKucT
          25.09.2015 16:44

          Как раз роутинг бы и хотелось видеть сразу весь

          Особенно для виртуального хостинга, когда на сервере живет 1к пользователей и 2.5к совершенно разных сайтов


          1. baldr
            25.09.2015 16:50
            +1

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


      1. hell0w0rd
        25.09.2015 15:06
        +1

        При желании достаточно один раз указать в конфиге сервера include /var/www/awesome_project/nginx.conf


        1. pewpew
          25.09.2015 15:08
          +1

          Можно такой конфиг править «на горячую»?


          1. SamDark
            25.09.2015 15:25

            Нет.


          1. hell0w0rd
            25.09.2015 15:49
            +3

            Смотря что иметь ввиду под «на горячую». Сам nginx конфиг не перезагрузит, однако без рестарта его можно загрузить, с помощью nginx -s reload или sudo service nginx reload . Это не остановит сервер, а просто даст ему команду перезагрузить конфигурацию, текущие запросы отработают по старой конфигурации, а новые — по новой.


            1. pewpew
              25.09.2015 15:54

              Собственно и apache можно заставить перегрузить конфиги. Но соль в том, что без доступа к перегрузке сервиса или перегрузки конфигов поправить файлы. Вопрос «зачем» — отдельная тема. Но в некоторых случаях увы — apache тут выигрывает.


              1. TaHKucT
                25.09.2015 16:46
                +3

                если файлов не очень много, то в сторону inotify посмотрите. (рут настраивает инотифи, пользователь правил файл, все работает само)


                1. Zelgadis
                  25.09.2015 20:06
                  -4

                  Ага, а потом одиз этих кусочков с ошибкой которая не дает перезапустить. Впрочем шаред хостинги не нужны. Никогда не видел смысла в ресурсах которые на шареде хостятся. Растрелять.


              1. hell0w0rd
                25.09.2015 16:50
                +2

                Я не знаю что это за случаи такие. Только шаред-хостинги, но ничего, они скоро умрут и их заменят saas решения, какая разница пользователю wordpress: использовать saas, или шаред хостинг?
                Соли в том, что на каждый запрос apache проверяет, не поменялся ли .htaccess — я не вижу, вижу только минусы.
                Кстати можно и nginx подпереть небольшим костылем, в виде watch файлов конфигов и nginx reload, если надо. Все это накостылить в виде демона и запустить из под нужного пользователя. Это если прямо сильно надо.


                1. merlin-vrn
                  25.09.2015 16:56

                  какая разница пользователю wordpress: использовать saas, или шаред хостинг

                  а если нужен не вордпресс?

                  (извините за бред в первоначальной версии комментария)


                  1. hell0w0rd
                    25.09.2015 17:00

                    По моему в этой версии комментария информации не сильно больше. А что нужно?


                    1. merlin-vrn
                      25.09.2015 17:02

                      dokuwiki. joomla. modx. тысячи их.

                      ps: я сам исключительно «за» saas wordpress, хотя бы за обновлениями следить не надо. просто не им единым. SaaS не замена PaaS (коим является шаред), и то, и другое имеет право на существование и свою нишу


                      1. hell0w0rd
                        25.09.2015 17:20

                        Ну тут можно продолжать спорить. joomla, modx, wp — это все не интересно клиенту. Ему нужен работающий сайт с удобной админкой. Быстро, дешего и безопасно.
                        Ну и тысячи не нужны даже разработчикам. Нужно максимум 100, и это с альтернативами по назначению сайтов.
                        Шареды до сих пор существуют из-за некомпетентности заказчиков/исполнителей, у них сейчас есть выбор, перейти на saas модель (или vps/vpc), либо просто вымирать.


                1. pewpew
                  25.09.2015 17:03
                  -1

                  Я не утверждаю, что apache лучше. Но в конкретно данном случае надо костылить.
                  Недавно делал проект на nginx + php (yii 1.1) + mysql и доволен.


            1. merlin-vrn
              25.09.2015 15:59
              -1

              Что будет, если конфиг некорректный? Он откажется его менять в памяти и останется работать со старым, или упадёт?

              (Проверять лень.)


              1. ValdikSS
                25.09.2015 16:04
                +5

                Останется, конечно.


              1. Gendalph
                26.09.2015 14:51

                nginx делает configtest (кажется nginx -t) и только потом перезагрузку конфига, если конфигтест фэйлится, то в основной error.log (обычно /var/log/nginx/error.log) пишется ошибка и ничего не перезагружается. А вот при nginx restart будут проблемы, если не придумать workaround.


                1. lexore
                  27.09.2015 11:08
                  +1

                  В некоторых дистрах init скрипт перед restart делает configtest.


                  1. merlin-vrn
                    28.09.2015 14:12

                    и что делать, если конфигтест сказал «конфиг кривой»? Отключать его? Типа, накосячил в своём виртуалхосте — страдай?


                    1. lexore
                      28.09.2015 14:14

                      Если конфиг кривой, то рестарт просто не делается.
                      В init скрипте апача такой тест есть давно.
                      Все для того, чтобы сервис не падал.


                      1. merlin-vrn
                        28.09.2015 14:29

                        Отлично. Ситуация: кто-то поправил сабконфиг, сделал это криво, теперь рестарт невозможен. Ну невозможен и хрен с ним, решил первый пользователь, меня и так всё устраивает. Другой пользователь решил поправить свой (другой) сабконфиг, и видит, что рестарт невозможен из-за ошибки первого. Что делать?


                        1. lexore
                          28.09.2015 14:47
                          +1

                          Если внутри IT отдела одной компании, то все просто.
                          Всыпать ремня первому пользователю и откатить из репы (или из бекапа) старый конфиг.

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

                          Но раз тут пошло обсуждение такого варианта, то давайте пофантазируем.
                          Наверное надо заранее предусмотреть, что пользователи будут писать фигню и каждый файл нужно будет проверять.
                          Придется развернуть песочницу, в которой нужно будет проверять каждый файл.
                          А так же репозитарии для этих файлов, чтобы их можно было легко откатить.
                          И если кто-то напишет фигню, сразу предупреждать «ошибка в конфиге, откат измений».
                          Хотя это все равно костыли.


                          1. baldr
                            28.09.2015 14:53

                            Давайте будем объективными — для шаред хостинга апач — самое то.
                            Для владельцев — поставил и работает, не надо колхозить с песочницами и глобальными конфигами… Их не очень волнует что у пользователей вдруг медленно работают сайты.
                            Для пользователей — за небольшие деньги получают достаточно простое управление через .htaccess — решение так себе, но работает. Кто начинает задумываться об улучшении — уходят на VPS.


                            1. schors
                              28.09.2015 14:59

                              > Их не очень волнует что у пользователей вдруг медленно работают сайты.

                              Это не правда. Нет никаких сведений, что апач работает медленнее.

                              > Кто начинает задумываться об улучшении — уходят на VPS

                              Это тоже не правда — там выше есть целая ветка обсуждения. Обычный VPS — это деградация ресурсов. Т.е. наоборот всё тсановится медленнее. Просто клиент перестаёт мешать всем остальным


                              1. baldr
                                28.09.2015 15:08

                                Ну, вроде, уже была ссылка что с .htaccess апач помедленнее отдает…
                                А насчет деградации — вы там правильно заметили что это очень зависит от хостера. Не хочу спорить — с хорошими у меня нет опыта, а плохие попадались всем, думаю.


                            1. lexore
                              28.09.2015 15:10

                              > Давайте будем объективными — для шаред хостинга апач — самое то.

                              Я, в общем-то согласен.


                        1. TaHKucT
                          28.09.2015 16:31

                          самый лучший вариант: вынести это в админку\панель управления. В том же isp-manager можно поправить конфиг nginx, но он не даст его сохранить если конфиг неправильный (я правда не уверен что это доступно «пользователям», но «администратору» точно доступно).

                          Причем если вы выносите конфигурацию в админку, вы можете сделать что-то типа «выставить основные параметры» (client_max_body_size, proxy_read_timeout и тп) на обычной страничке с «название параметра, выпадающий список параметров, человекопонятный комментарий параметра», а давать возможность написать кусок конфига только после нажатия кнопки «я крутой чувак и понимаю что делаю».
                          Это снизит колво обращений в саппорт, увеличит лояльность пользователей и позволит сказать «мы первые в рунете, кто дал пользователям такую возможность»


    1. dim_s
      25.09.2015 14:17
      +4

      Я думаю, как минимум все php хостинги, т.к. у многих есть поддержка .htaccess.


      1. baldr
        25.09.2015 14:21

        Да, для shared-хостинга, согласен, наверное. .htaccess в этом случае — лучший вариант.


        1. merlin-vrn
          25.09.2015 15:54
          +4

          Для каких-то случаев .htaccess хорош. Но приходится обходить дерево и парсить все .htaccess при каждом запросе! Непосредственно в документации Apache сказано, что его использовать не рекомендуется, и это названо одной из причин.

          Ну и строго говоря, современным веб-приложениям точное соответствие веб-пространства и структуры директорий требуется исключительно для статики. Как правило, все динамические запросы у них приходят в одну точку входа. Зачастую, всё по традиции помещается в documentroot, но доступ ко всему, кроме точки входа и статики, закрывается .htaccess. А ещё .htaccess в таких случаях используется для переписывания запросов, чтобы вместо уродливых php-шных урлов снаружи были видны красивые «сеошные».

          Гораздо эффективнее перечитывать конфиг не в ответ на запрос, а в ответ на изменение. Вполне достаточно для задач шареда было бы, если бы на каждый виртуалхост был ровно один редактируемый пользователем файл с конфигурацией, за изменением которого следит веб-сервер (например, с помощью inotify). Все переписывания запросов можно положить туда. А всё, кроме точек входа и статики, выносить за пределы documentroot, чтобы вместо закрывания доступа туда — этого доступа просто не было бы изначально.


    1. grossws
      25.09.2015 18:15

      Поддержка аутентификации через ldap, например. Хотя в новых версиях nginx появился auth_request, который позволяет дернуть внешнее веб-приложение для аутентификации и авторизации.


    1. schors
      26.09.2015 12:40

      А в чем разница между fpm и apache?


      1. lexore
        27.09.2015 11:09

        Судя по вашему профилю, вы в курсе и решили просто потроллить? :)


        1. schors
          27.09.2015 13:15

          Естественно я в курсе, поэтому и спрашиваю. Зачем менять apache на fpm мне действительно не понятно.


          1. lexore
            27.09.2015 13:21

            В хайлоаде удобно держать раздельно nginx и php.
            По отдельности их проще мониторить, тюнить и ловить баги или узкие места.
            «Все-в-одном» Apache+mod_php в этом плане не удобен.

            Ну и когда у тебя в большинстве мест наружу смотрит nginx, удобнее держать один инструмент, чем два.
            Особенно, когда профита от Apache нет.
            Насчет минусов от Apache тут можно много холиварить, но насчет плюсов чет никто не высказывается)


            1. schors
              27.09.2015 18:11
              +1

              Профит от апача по сравнению с fpm? Гибкость конфигурации? Больше потенциальных возможностей? Бессмысленность в данном случае неапача? Недоверие к php? :) Не, серьёзно. Был некий смысл в fpm на том этапе, когда мультиинстанс апач боялись запускать. не было всяких mmap, и всё такое. У меня в 2009 году встала дилема — оставить «котеровский патч», php-fpm (он тогда ещё сторонним модулем был) или сделать мультиинстанс апач. Подёргал, посмотрел, посчитал, потестировал. Было разве что покидать обычный апач и городить пулы. Но это практически не обсуждалось. А в остальном fpm не показал никакого профита. И я вот с php 5.3 смотрю как на него все прямо кидаются и не понимаю :)


              1. Gendalph
                27.09.2015 18:29

                С nginx+fpm вы настраиваете, nginx, php.ini и пуллы для fpm. Кстати, встроенный отчет у fpm немного лучше, чем у apache — умеет отдавать json (попробуйте ?full&json). Также воркер fpm должен быть легче, чем воркер apache с mod_php.
                С nginx+apache вы настраиваете nginx, apache и php.ini. Настройка и защита apache обычно сложнее чем настройка пуллов fpm.


              1. lexore
                27.09.2015 18:30
                +2

                А, вы про применение с точки зрения владельца шаред хостинга)
                Согласен, вам от апача не избавиться.
                Вам проще давать клиентам на выбор несколько апачей с разными версиями php через mod_php.
                Когда у меня был минихостинг, я тоже сделал nginx+apache+mod_php, чтобы все работало и не было проблем.
                В этой теме у людей чаще ситуации «сайт для компании» или «компания одного сайта».


              1. alekciy
                27.09.2015 23:15

                fpm шёл не модулем, а патчем от Нигматулина. Профит был в потребляемой ОЗУ, пулах со своими UID, choot, разных версиях php, более удобному мониторингу. И на апаче можно поднять такую инфраструктуру, но на связке nginx+php-fpm это удобнее. А уж когда патч приняли и оно появилось в репозитории из коробки…


                1. schors
                  28.09.2015 14:15

                  > Профит был в потребляемой ОЗУ

                  А? Можно подробнее с этого места. В процентах желательно :)

                  > но на связке nginx+php-fpm это удобнее.

                  При наличии систем управления серверами вообще без разницы.


                  1. alekciy
                    28.09.2015 14:56

                    На сколько сейчас помню воркеры апачей стабилизировались где-то в районе ~50мб, fpm — 25мб.


                    1. schors
                      28.09.2015 15:00

                      50Mb воркеры апача? Это простите чего 50Mb? :) Хорошо если 5Mb он под себя отжирает. Инстанс. Сколько воркер — я даже не знаю как это посмотреть.


                      1. alekciy
                        28.09.2015 16:13

                        htop RES.


                        1. schors
                          28.09.2015 16:30

                          И что он нам показывает? Не, давайте вот прямо — что это за цифра?


                          1. alekciy
                            28.09.2015 17:02

                            Резидентная память.

                            P.S. Не, не надоело?


                            1. schors
                              28.09.2015 17:12

                              Нет конечно. А он показывает да, cow она, или там шарит он её с чем-то? Или может это конфиг там так разросся? Что похоже на правду — апач ведь засасывает конфиг и потом форкает это всё безобразие на каждый инстанс, а fpm скорее всего только свою часть у каждого пула оставляет. Что в итоге одно и тоже, но выглядеть будет по-разному. Запустите без mod_php — посмотрите. Дальше всё казуистика — fpm использует тот же код, что и в mod_php даже по тому же принципу.


                              1. alekciy
                                29.09.2015 08:03

                                Я в курсе. Рад, что у вас все хорошо. Действительно.


          1. VolCh
            27.09.2015 23:35
            +1

            Вы продолжаете троллить? Apache поддерживает FastCGI «из коробки» лет 5 как минимум.


            1. schors
              28.09.2015 14:00

              И? Как это объясняет замену apache+mod_php на fpm


              1. VolCh
                28.09.2015 16:51

                Вопрос некорректный. Можно заменить mod_php на php-fpm не меняя apache, можно заменить apache+mod_php на nginx+php_fpm, можно заменить nginx+apache+mod_php на nginx+php-fpm. Вы про какую замену?


                1. schors
                  28.09.2015 16:55

                  nginx+apache+mod_php на nginx+php-fpm. Честно говоря «apache+mod_php» голой попой в сеть даже я в массе не застал со своей седой бородой. Во времена до nginx использовали squid, потом появился oops, а потом nginx.
                  P.S. Причем, в те времена это было ещё более оправданно, чем в нынешние — модемы же, 33600 уже хорошо, а у кого-то и их не было.


                  1. VolCh
                    29.09.2015 13:18

                    Я вижу две с половиной причины для такой замены:
                    — упрощение администрирования связки
                    — снижение потребление ресурсов связкой (не критическое, но заметное, по крайней мере лет назад было заметным)
                    — теоретичtская (до продакшена ни разу не довёл, потому только половина причины) возможность подменить php-fpm на любую другую реализацию FastCGI (прежде всего честную для PHP) без особой правки конфигов nginx.


                    1. schors
                      29.09.2015 13:27

                      > упрощение администрирования связки

                      Практически нет. Более современный json в fpm конечно ок, но де-факто это разве что потешить внутреннее чувство гармонии.

                      > снижение потребление ресурсов связкой (не критическое, но заметное, по крайней мере лет назад было заметным)

                      Вы считали, или просто помните опыт ложного теста прошлых лет? Такое бывает. Я без наезда. По факту 6 лет назад разницы не было никакой. Я честно тут в запарке и не стал выше в полемику вдаваться. Но я реально был готов на хостинге подсолить как-то в панельку и отказаться от .htaccess (или дать выбор) если бы это дало прирост производительности, сколь либо заметный. Но тесты показали…

                      > возможность подменить php-fpm на любую другую реализацию FastCGI

                      Ой, там такой простой шаблон, что прямо проблемы вообще нет. Особенно учитывая, чо скорее всего конфиги всё равно автоматом правятся. Так ведь? :) Да и больше Вы запаритесь с «честным FastCGI». Кстати, попробуйте SCGI в кастомном проекте. FastCGI он достаточно сложный, громоздкий и с перебором.


                      1. VolCh
                        30.09.2015 19:21

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

                        Помню смутно результаты своих тестов от хелловодрда до друпала с вордпрессом с желанием добиться объективных результатов, а если не объективных, то в сторону апача, чтобы не учить нового зря :)

                        Неа, всё ручками :) Неделей раньше вы где были? А сейчас отпуск заканчивается… :(


  1. iSage
    25.09.2015 15:46
    +2

    >Nginx не имеет возможности самостоятельно обрабатывать запросы к динамическому контенту.
    nginx-perl и nginx-lua с вами не согласны


    1. ibKpoxa
      25.09.2015 15:58
      +1

      А теперь есть еще и поддержка JS.


  1. romy4
    25.09.2015 15:58
    +3

    При отключении поиска .htaccess в апаче, его скорость отдачи серьёзно поднимается. Для понимания ссылки: ~4К запросов в секунду — это нормальная скорость для вордпресса под nginx с включёнными кешами. Но мне лично apache удобнее настраивать, особенно из-за mod_macro и mod_php, и дабы не заниматься прикладным онанизмом с fastcgi. Скорость, в итоге, выходит сравнимо одинаковая.


    1. merlin-vrn
      25.09.2015 16:00

      Кто-то когда-то принял популярное, но технически кривое решение (внедрил поддержку .htaccess), и теперь все расхлёбывают.


      1. romy4
        25.09.2015 16:08

        В apache достаточно было бы сделать решение в котором бы перезагружался только конфиг одного virtualhost и всё было бы в шоколаде: пользователи б могли иметь конфиг хоста у себя в хомяке со своими правами.


        1. merlin-vrn
          25.09.2015 16:09

          о чём я и говорю: habrahabr.ru/post/267721/#comment_8590895


          1. romy4
            25.09.2015 16:32

            Кстати, вот подтверждение более высокой скорости Apache без .htaccess и без накладных расходов на fastcgi над nginx.


            1. baldr
              25.09.2015 16:46

              Не очень удачный пример. Статья оценена в -36, в комментариях народ сомневается в измерениях, да и настройки тоже непонятны.


  1. bondsman
    25.09.2015 16:50
    -13

    Nginx уже умеет Subversion?


    1. bondsman
      26.09.2015 13:57
      -2

      Господа минусующие, оставляйте пожалуйста комментарии поясняющие ваше недовольство.
      По теме статьи — пока один продукт не поддерживает функционала второго, сравнивать особо нечего. Они оба хороши для своих задач.
      Ну и конечно же их надо уметь «готовить»…


      1. Gendalph
        26.09.2015 15:05

        Что-то делают: romantelychko.com/blog/1177
        Лично для меня nginx более понятен чем apache, а по опыту работы с обоими nginx еще и более надежен — apache умудряется вешаться и терять запросы на ровном месте через неделю после запуска.


        1. schors
          26.09.2015 15:13
          +1

          Расскажите об этом подробнее. О потере запросов и завесах.


          1. Gendalph
            26.09.2015 15:22
            +2

            Тормозной магазин на prestashop, ubuntu 14.04 — nginx+apache(mpm_event, потом mpm_prefork)+fpm+mysql (ssd) где-то на вторую-третюю неделю начинаются проблемы при пиковой нагрузке — TTFB корзины иногда занимает >3 секунд, что неприемлемо (при нормальной работе FPL ~2.5с), значительно чаще вылетают gateway timeout, хотя судя по логам fpm запрос отработал. Рестарт апача лечит проблему на ~неделю.
            Трижды в этой схеме fpm просто падал — раз и исчез. В логах — пусто.
            До этого был debian 7, nginx+php-fpm+mariadb — год таких проблем небыло.


            1. schors
              26.09.2015 15:36
              +1

              > nginx+apache+fpm+mysql

              Это шутка такая? Кстати, можно поподробнее вот об этом месте между apache и fpm


              1. Gendalph
                26.09.2015 15:59

                Почему шутка? Архитектурно apache с mpm_event и php-fpm очень близок к nginx+php-fpm и я, проведя небольшой тест, решил что всё будет работать как нам хотелось. Оно вобщем-то так и работало, пока не запустили крупную рекламную кампанию.
                А как вы бы организовали архитектуру?


                1. schors
                  26.09.2015 16:18

                  Вы не ответили на вопрос — про связку apache и fpm.


                  1. Gendalph
                    26.09.2015 16:21

                    Prestashop полагается на .htacces, как это часто бывает. Для его обработки попросили использовать apache.
                    fpm подключается в виртуальном хосте приблизительно такой конструкцией (быстрый гугл)
                    ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://127.0.0.1:9000/path/to/your/documentroot/$1


                    1. schors
                      26.09.2015 16:40
                      +1

                      Мне просто интересно было. А просто mod_php не?


                      1. Gendalph
                        26.09.2015 16:49

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


                        1. schors
                          26.09.2015 17:30
                          +6

                          Не мучайтесь. Просто уберите нафиг fpm и просто поставьте mod_php. Бессмысленная схема вот совсем.

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


                          1. Gendalph
                            27.09.2015 16:07

                            Нам лучше избавиться от apache — толи мы его готовить не умеем, толи он действительно не совсем для наших целей, но на 2 из 4 других серверов его надо перезапускать раз в неделю, чтоб он не повесился через ~месяц.
                            Там где он работает нормально нету больших нагрузок (они в разы ниже чем на этом магазине).

                            За подсказку о несогласованности лимитов — спасибо, будем думать, но в первую очередь в сторону избавления от apache.


                            1. schors
                              27.09.2015 18:19
                              +3

                              Просто возьмите и поставьте mod_php. Я сходу не вижу подводных камней быстрого переключения на mod_php без выключения fpm. Не понравится — вернете обратно. Заодно не придётся разбираться несогласованностью. Ну и конечно только prefork и конечно лимитируйте сколько у вас один обработчик может обработать запросов — 1000 например. Ну и дополнительно — попробуйте как бы повторить в префорке конфигурацию fpm по стартуемым серверам, удерживаемым и максимальным. Вообще желательно эту цифру держать постоянной, чтобы они там себя не размножали — это дорогая операция.


                              1. VolCh
                                27.09.2015 23:39

                                Разве каждый (включая статику) запрос не начнёт жрать больше ОЗУ?


                                1. schors
                                  28.09.2015 14:03

                                  С чего? Насколько больше? Зачем им отдавать статику (хотя он и её норм отдаёт)?


                                  1. VolCh
                                    28.09.2015 16:53

                                    mod_php будет в каждом процессе apache, даже для отдачи css/js.


                                    1. schors
                                      28.09.2015 17:00

                                      И что? Он есть и есть. Пул и пул. А fpm и вообще не умеет отдавать статику. И тоже пул. Ужас, правда? Вы намекали конечно же на nginx, но кто же мешает его перед apache поставить? 2015 год. Уже в 2002 никто голым задом апач в сеть не выставлял. Я как-то даже теряюсь


        1. bondsman
          26.09.2015 20:30

          В указанной статье абсолютно ничего не делают для публикации svn по http(s).


  1. reji
    25.09.2015 17:10

    Apache ещё жив, так как большинство приложений поставляется с конфигом апача. Самый недавний пример — owncloud.


    1. baldr
      25.09.2015 17:13

      Никто не спорит что он жив. Мы пытаемся обсудить его преимущества против nginx, как и заявлено в сабже.


    1. lexore
      25.09.2015 19:30
      +3

      Owncloud отлично идет на nginx+php-fpm, я сам в этом убедился.
      Да там и в доке есть описание конфига на nginx.


    1. Meklon
      26.09.2015 10:32
      +1

      Nginx + php-fpm + mariaDB работает субъективно быстрее га стандартных настройках.


  1. ibKpoxa
    25.09.2015 18:25
    -4

    Нет смысла сравнивать nginx и apache, как это делает автор статьи, это два инструмента с разным оптимальным использованием, надо знать их сильные места и использовать их, возможно одновременно.


    1. baldr
      25.09.2015 19:40
      +6

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


      1. ibKpoxa
        25.09.2015 23:06

        Кроме того, что то и другое это web сервер и могут раздавать статику, чем они похожи? Не по мелочам, а крупными мазками.


        1. baldr
          25.09.2015 23:16

          А разве мало того что это веб-сервер? Особенно если нужен именно веб-сервер — что выбрать? И как?
          И почему только «раздавать статику»? У них у обоих очень богатые возможности по роутингу, например, или проксированию.
          Если вы умеете писать расширения для них — можете написать очень эффективное, в плане производительности, приложение.


          1. ibKpoxa
            25.09.2015 23:21

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


            1. baldr
              25.09.2015 23:28

              Я, наверное, не понимаю вас. Почему этого мало? Пользователю нужен веб-сервер. Это задача. Почему он должен смотреть на апач, но не на nginx? Именно это здесь обсуждается в статье и в комментариях.
              Какие убийственные аргументы вы можете привести с вашим опытом?


              1. ibKpoxa
                25.09.2015 23:33
                -2

                Пользователю нужен веб сервер? Вы меня удивляете, пользователю надо решать его задачи, ему не нужен веб сервер, ему может быть нужен сайт или ему нужен блог, в жж его не устраивает из-за политики, а если этот человек может настроить вебсервер, то это уже не пользователь. В админу далеко не всегда надо сравнивать инструменты, ему надо показать их сильные стороны. Люди решают задачи, а не выбирают веб сервер, а чтобы решить задачу, надо понять какой инструмент её может решить, а сравнение без выбора оно не конструктивно.


                1. baldr
                  25.09.2015 23:50
                  +1

                  Пожалуйста, не ёрничайте. Специально для вас — здесь «пользователь» — это тот, кому нужно выбрать веб-сервер. Давайте не будем лить воду.
                  Вы нам даете понять что уж ваш-то опыт позволяет принять правильное решение. Но как раз от вас не было ни одного примера в пользу того или иного. Раз уж вы прекрасно представляете что может апач, а что nginx — уж, поделитесь, пожалуйста, мудростью — для каких задач кто из них подходит лучше.
                  Вот мы тут ругаем апач — возможно, вы знаете что-то такое особенное где именно он всех порвет?


                  1. bondsman
                    26.09.2015 14:01
                    +1

                    В большинстве случаев «пользователь» выберет тот веб сервер, по которому найдет большее количество гайдов в бложиках.
                    Осознанным выбором это трудно назвать.


                    1. VolCh
                      27.09.2015 23:40

                      Вполне осознанный выбор по критерию «поддержка сообществом»


  1. lexore
    25.09.2015 19:48
    +1

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

    На практике nginx и быстрее и удобнее в настройке.
    Поэтому я бы дал практический совет: использовать nginx всегда, когда есть возможность.
    Даже на шаред хостингах часто фронтендом стоит nginx (без возможности настройки), а уже за ним настраиваемый апач и настраиваемый php.

    Да, вообще без Apache на шаред хостингах не обойтись, если только не городить кучу костылей (которые потом ещё админить).
    Ну так и пусть Apache остается в нише шаред хостингов.
    Шаред-хостинги — это исчезающая ниша во времена дешевых vps/lxc.
    Шаред-хостинг можно использовать для небольших малонагруженных проектов.
    Но когда нагрузка возрастет, нужно будет переезжать на отдельный VPS или VDS с nginx на борту.


    1. forgotten
      26.09.2015 10:50
      -2

      Существование шаред-хостингов при наличии digitalocean вообще выглядит каким-то непонятным рудиментом.


    1. XolodIT
      26.09.2015 18:08
      +2

      >Но когда нагрузка возрастет, нужно будет переезжать на отдельный VPS или VDS с nginx на борту.

      Заблуждение.


      1. schors
        26.09.2015 18:10
        +1

        Народ не понимает разницу между шаред-ресурсами и гарантированными так же как и разницу между nginx и apache :) Они реально не понимаю, что гарантированные ресурсы по определению меньше и медленнее.


        1. XolodIT
          26.09.2015 18:36
          +2

          По вашему у vds гарантированные ресурсы гарантированнее чем у шаред-хостинга -)?


          1. grossws
            26.09.2015 22:44

            Это сильно зависит от того где и за какие деньги. Что на xen, что на esxi/vcloud вполне можно не использовать overcommit по ресурсам и memory balooning. Но стоить это будет, очевидно, больше.


            1. XolodIT
              26.09.2015 23:20
              +1

              Вы с schors не путайте мягкое с теплым. Честность лимитов на совести хостера, а не в разнице шаред\vds. И в этом смысле они не отличаются, разве что на шареде уж совсем мимишные ресурсы можно выделить под какой-нибудь тариф для статики.


              1. grossws
                26.09.2015 23:40

                Вы знаете хоть один шаред хостинг без оверкоммита по ресурсам? Там это имплицитное свойство. Иногда, просто, не по всем ресурсам. Т. е. гарантированный диск или пропускную способность сети вы получить, но, скажем, гарантированный cpu уже делать экономически неоправдано. Может, что-то изменилось в последнее время, шаред хостингом не пользовался уже очень давно.

                Ещё граница несколько размывается всякими openvz/lxc/docker, где появляются всякие vps и IaaS.

                В случае же vds — всегда есть реальный выбор, о чём я и писал выше.


                1. XolodIT
                  27.09.2015 00:13
                  +3

                  >Вы знаете хоть один шаред хостинг без оверкоммита по ресурсам?
                  Знаю и не один.

                  > Там это имплицитное свойство.
                  Вы чего-то знаете о вирутализации чего не знает никто)? Накладные есть везде.

                  >гарантированный cpu уже делать экономически неоправдано
                  во-первых оправдано, во-вторых если дорожите своими клиентами и качеством услуг в условиях высокой конкуренции, в-третьих это также относится и к vds, и в-четвертых:
                  >>Честность лимитов на совести хостера, а не в разнице шаред\vds.

                  >В случае же vds — всегда есть реальный выбор, о чём я и писал выше.
                  Такой же выбор может дать и шаред хостинг.

                  Я не говорю, что vds плохо, шаред хорошо. Клиентам с разной компетенцией, и разным задачам — подходит своё. Но это:
                  >Но когда нагрузка возрастет, нужно будет переезжать на отдельный VPS или VDS с nginx на борту.
                  заблуждение, отчасти порожденное некоторыми хостерами по ряду различных причин.


                  1. grossws
                    27.09.2015 02:51

                    Вы чего-то знаете о вирутализации чего не знает никто)? Накладные есть везде.
                    Далеко не весь рынок шареда (как минимум тот, что был раньше) использует виртуализацию. Часть прекрасно жила на пачке пользователей и не ведала о том, что существует какой-то openvz (особенно, до 2005 года, да).

                    Мой тезис в том, что шаред становится по ресурсам столь же дорогостоящим, как полноценные виртуалки в xen/kvm, если не использовать overcommit. Некоторая экономия получается на уменьшении сложности управления этим хозяйством при использовании контейнеров и уменьшении оверхеда засчёт запуска кучи ядер.

                    Я не говорю, что vds плохо, шаред хорошо. Клиентам с разной компетенцией, и разным задачам — подходит своё. Но это:
                    Но когда нагрузка возрастет, нужно будет переезжать на отдельный VPS или VDS с nginx на борту.
                    заблуждение, отчасти порожденное некоторыми хостерами по ряду различных причин.
                    Это можно воспринимать, как заблуждение пока разговор касается того, что влезает на маленькие и дешевые vps/vds. Когда вам нужно иметь даже мелкие десятки гигабайт памяти на ноду — шаред уже выглядит странновато, согласитесь. Тут либо железо, либо нормальные виртуалки, либо PaaS.


                    1. schors
                      27.09.2015 02:58
                      +1

                      > даже мелкие десятки гигабайт памяти на ноду

                      Смакую уже три минуты. Мне всегда кажется, что я попал на планету, где каждая вторая фирма — Google. «У нас ферма в сотни серверов», «мы подымаем 1000 контейнеров», «жалкие десятки гигабайт». Чем вы вообще все занимаетесь? :)


                      1. grossws
                        27.09.2015 03:20

                        Ну, масштабы гугла несколько иные, хоть и порядок порядка тот же. Там разговор за миллионы серверов, если что.

                        У меня всё более-менее скромно, в рамках десятков серверов. Ну а касательно памяти — не всем надо статику раздавать.


                        1. schors
                          27.09.2015 13:11

                          Я к тому, что 10Гб это _очень_ много и «жалкие» тут не приемлемо. Как и «не всем надо статику». Нельзя приводить такие цифры как шаблон использования, потому что они огромны. Да, у меня тоже есть сервера с 128Гб памяти. Сайты. Но не типовые. Причем далеко не типовые. Говорить людям «вам нужен вот этот звездолёт» в общем случае я не буду, хотя конечно получить свой процент с продажи мне выгодно.


                          1. grossws
                            28.09.2015 01:27

                            Я к тому, что 10Гб это _очень_ много и «жалкие» тут не приемлемо.
                            У меня оно и не звучало. А «мелкие десятки» — это, грубо говоря, 8-32G.

                            Я предполагал, что мы говорим про рынок виртуальных серверов в целом, а не только типичный хостинг, где клиенту много не надо, и мои цифры уже не являются чем-то огромным.


                            1. schors
                              28.09.2015 14:05

                              Вообще ещё являются. Это реально ещё огромные цыфры


                              1. grossws
                                28.09.2015 14:16

                                У нас разные представления о масштабах, это вопрос терминологии. Для меня огромные цифры (в контексте RAM на одной ноде) — это 0.5 TiB и выше; большие — от 64 до 512 GiB.

                                И наличие предложения типа 128 GiB+ (например, 122, 160 и 244 GiB на ec2) говорит о том, что кому-то такое количество памяти вполне нужно части массовых клиентов.


                    1. VolCh
                      27.09.2015 23:47

                      Мой тезис в том, что шаред становится по ресурсам столь же дорогостоящим, как полноценные виртуалки в xen/kvm


                      Какой вариант для бизнеса (средне-мелкого) будет более выгоден, по-вашему:
                      1. Шаред-хостинг, где всё администрирование на хостере
                      2. Полноценная виртуалка, где всё администрирование на клиенте (минимум два админа на 40 часов в неделю, плюс сверхурочные для хоть кажущейся поддержки 168 часов в неделю)
                      3. Та же виртуалка, с администрированием на хостере
                      4. Та же виртуалка, с администрированием на аутсорсе


                      1. grossws
                        28.09.2015 01:34

                        Шаред-хостинг, где всё администрирование на хостере
                        Такого практически не бывает: обновление самого веб-приложения, миграции базы, настройка прав доступа и т. п. всё равно останется на клиенте, если не брать SaaS.

                        Эти же затраты никуда не исчезнут при использовании остальных вариантов. Но это относится к мелкому и среднему не-ITшному бизнесу (т. е. пока нет, как минимум, выделенного подразделения IT или аналогичного контракта на аутсорсе), т. е. до мелких сотен сотрудников.

                        Что же до оценок в 2x40 на поддержку, не считая сверхурочного времени — выглядит завышенным. Если мы всё ещё говорим про мелкий и средний бизнес. Опять же, если эта поддержка касается какого-либо mission-critical софта, то они будут и там, и там.


                        1. VolCh
                          28.09.2015 02:38
                          +1

                          Под администрированием я не имел в виду уровень администрирования приложения, только инфраструктуры для его исполнения: веб-, апп-, бд-сервер, которые как-то линкуются к коду и данным приложения.

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

                          2х40 + сверхурочные — это минимальная оценка администрирования инфраструктуры для веб-приложения, реализующего любые активные (изменяющие договорные параметры отношений с клиентом-пользователем) бизнес-процессы 365х24.


                1. schors
                  27.09.2015 02:26
                  +1

                  > Там это имплицитное свойство

                  А на VDS конечно вы всё прозрачно видите, ага. Посмотрите на линейку тарифов DigitalOcean например. Попробуйте посмотреть кратность ресурсов от старших к младшим. И внезапно выползет оверселинг ядер проца. А на практике ещё и честное деление iops превращает хваленые SSD в какие-то флешки.


                  1. grossws
                    27.09.2015 02:39

                    Я смотрю на то, чем пользуюсь. С честными iops по iscsi, честными ядрами, памятью без memory baloon и т. п.

                    И нигде не отрицаю, что на рынке vps/vds есть куча предложений с overcommit'ом, как и на рынке shared'ов.

                    Приводить в пример сверхдешёвый IaaS — это несколько странно. Известно к чему ведёт кроилово. Сравнивать надо с нормальным ценовым сегментом. Конечно, открытым остаётся вопрос доверия поставщику услуг. Но в случае, скажем, амазона — всё честно и прозрачно. У меня, правда, задачи не сайты хостить, так что требования по ресурсам принципиально другие и шаред мне не интересен.


                    1. schors
                      27.09.2015 03:05

                      > Я смотрю на то, чем пользуюсь. С честными iops по iscsi, честными ядрами

                      «У меня тут кастомное решение с крутыми параметрами и не жалкими десятками гигабайт, но я поддержу чувака, который рассказывает о редпочтении шареда перед vds». Круто.

                      > памятью без memory baloon и т. п.

                      Некстати, но вдруг заинтересовался, а вас не смущает mmap/ksm/чтотамеще для файловых объектов на всех современных ОС и copy-on-write всей памяти? Лет так 10 уже. Ну так.

                      > сверхдешёвый IaaS

                      Это DO-то сверхдешевый?


                      1. grossws
                        27.09.2015 03:43

                        Это DO-то сверхдешевый?
                        Сравните с AWS.

                        Например, 32G RAM, 12 vCPU и 320G SSD у DO — $320.

                        У Амазона m4.2xlarge с 32G RAM, 8 vCPU и 320G SSD — уже около $400.
                        Следующий близкий по конфигурации c4.4xlarge с 30G RAM, 16 vCPU и 320G SSD — $670.
                        Это в случае, если вам не нужны более-менее большие IOPS, тогда стоимость дисков подрастёт.

                        Некстати, но вдруг заинтересовался, а вас не смущает mmap/ksm/чтотамеще для файловых объектов на всех современных ОС и copy-on-write всей памяти? Лет так 10 уже. Ну так.
                        Иии? Если вы в контексте виртуализации — то при чём здесь mmap — не очень понятно, в виртуалку обычно отдаются виртуализованные или реальные диски. Делать их mmap немного странно.
                        KSM может быть включен, а может быть выключен (в силу опасений по поводу security, например).
                        Так же, как thin pool'ы могут использоваться, а могут и не использоваться в случае СХД.
                        CoW памяти — это что-то странное. Не расскажете поподробнее?


                        1. schors
                          27.09.2015 13:26

                          > Сравните с AWS

                          Не деньги. Кратность ресурсов. Очень заметно когда начинается оверселлинг. Пока они кратны — нет. Заодно кстати можете рассказать для Амазон, будем тоже знать.

                          > Если вы в контексте виртуализации — то при чём здесь mmap

                          Потому что у некоторых именно mmap обеспечивает связь диска с файлом на уровне ядра.

                          > в виртуалку обычно

                          Вообще я прицепился к презрительному отношению к балунингу ))) Не вижу разницы )))

                          > CoW памяти — это что-то странное

                          Любой fork() не копирует память, я делает вот этот самый cow. Любой exec() файла (если уже его кто-то сейчас exec()) не читает файл заново, а делает cow на уже загруженный. Насколько я понимаю это уже давно у всех.


                          1. grossws
                            28.09.2015 01:49

                            Не деньги. Кратность ресурсов. Очень заметно когда начинается оверселлинг. Пока они кратны — нет. Заодно кстати можете рассказать для Амазон, будем тоже знать.
                            Что на кратных тарифах мешает делать overcommit? Опять же, можно продавать гарантированный минимум с определённой верхней границей буста, но, на мой взгляд, это актуально по cpu. По памяти — уже больнее, т. к., если мне динамически уменьшат память, в которой были не дисковые кэши, а данные, то они идут либо в swap, либо процесс получит неприятный сигнал от oomkiller'а.

                            Потому что у некоторых именно mmap обеспечивает связь диска с файлом на уровне ядра.
                            mmap — в userspace, прокидываемые в виртуалку устройства обычно избегаю лишнего перехода по vfs-стеку, не говоря уже о лишнем скачек userland/kernelland. В общем, я вас несколько не понял в этом моменте.

                            Вообще я прицепился к презрительному отношению к балунингу ))) Не вижу разницы )))
                            Оно не презрительное, оно настороженное. По тем причинам, что при увеличении размера baloon'а данные могут улететь в swap или процесс получить сигнал от oomkiller'а.

                            Любой fork() не копирует память, я делает вот этот самый cow. Любой exec() файла (если уже его кто-то сейчас exec()) не читает файл заново, а делает cow на уже загруженный. Насколько я понимаю это уже давно у всех.
                            Ааа, вы про clone и иже с ним. По фразе
                            вас не смущает mmap/ksm/чтотамеще для файловых объектов на всех современных ОС и copy-on-write всей памяти?
                            было не очевидно, что вы имеете ввиду процессы в рамках одного хоста, а не между виртуалками. Стоит сказать, что это не всегда так: есть vfork, который не копирует таблицы страниц памяти родительского процесса и применим для процессоров без MMU, где fork не может использовать CoW.


                        1. VolCh
                          27.09.2015 23:54

                          Например, 32G RAM, 12 vCPU и 320G SSD у DO — $320.

                          У Амазона m4.2xlarge с 32G RAM, 8 vCPU и 320G SSD — уже около $400.


                          Цены одного порядка в общем случае. Тут скорее роляет не +- 20% по ядрам или цене, а субъективная вера в надежность партнера.


                          1. grossws
                            28.09.2015 02:14

                            Возьмите среднее между конфигурациями, которые я привёл для ec2, получите $535, что в 1.67 раз больше $320 на do. Это уже не совсем 20%.

                            Это не считая того, что мне не известно, какие по производительности ядра на do, когда у амазона указана производительность в ecu и, ещё, используемые ядра для новых конфигураций (соответственно, можно нормировать на их производительность, если захочется). А взяв m4 или c4, я могу быть уверен, что мне будут доступны avx-2 на вполне приличных xeon e5 третьего поколения, что совсем прекрасно (правда, только в некоторых узких вычислительных кейсах).

                            Есть неплохая статья со сравнительным анализом по производительности в разных облаках, хотя и несколько старая: blog.cloudharmony.com/2010/05/what-is-ecu-cpu-benchmarking-in-cloud.html


                            1. VolCh
                              28.09.2015 02:45

                              Да даже 200% разницы обычно в таких раскладах объективного значения не имеют. Вот вы начинаете говорить про субъективные вещи, типа у того есть какие-то бенчмарки, а у того нет, можете быть вы в чём-то уверены или нет (у вас могут быть какие-то гарантии по договору или просто предложениям, но если Газпром (тупо для рифмы и намёк на «эффективных менеджеров») решит купить облачный бизнес Амазон и денег не пожалеет, то вы уверены, что эти гарантии сохранятся?)


                      1. grossws
                        27.09.2015 03:51

                        «У меня тут кастомное решение с крутыми параметрами и не жалкими десятками гигабайт, но я поддержу чувака, который рассказывает о редпочтении шареда перед vds». Круто.
                        Не стоит обижаться, что я могу соглашаться с некоторыми аргументами вашего оппонента.
                        Когда разговор идёт о сотнях пользователей с мелкими виртуалками на одном хосте — это требует больше ресурсов, чем на то же количество пользователей на каком-нибудь proxmox/openvz за счёт того, что у всех пользователей будет одинаковые ядро, ОС и базовые библиотеки, загруженные в одной копии. Против зоопарка в виртуалках. Это может позволять получить больше ресурсов за те же деньги. При меньшей гибкости, меньшей (хотя, обычно достаточной) изоляции и т. п.


                        1. schors
                          27.09.2015 13:20

                          Я конечно же хотел сказать наоборот. Это был выпад на эпитет «жалкие 10Гб» в топике «когда-то приходит время переходить с шареда на вдс, чтобы было быстрее»


                    1. VolCh
                      27.09.2015 23:49

                      Сравнивать надо с нормальным ценовым сегментом.


                      Нормальным по какому фактору? Средняя цена как цена/количество поставщиков? Или надо какие-то весовые коэффициенты и/или фильтры вводить?


              1. schors
                27.09.2015 02:22

                Нет, при условии резервных ресурсов vds всё равно только доля. И в этих условиях шаред сильно выигрывает. Но проигрывает по предсказуемости конечно. Это И мягкое, И теплое. Два предмета.


          1. schors
            27.09.2015 02:20

            Конечно. Больше вам сожрать не дадут (есть конечно бурст, у кого есть, и если есть куда). А на шареде используется вся мощь ресурсов, для данного процесса.


            1. XolodIT
              27.09.2015 09:04

              >на шареде используется вся мощь ресурсов, для данного процесса.
              У нас на этот счет другой опыт благодаря CL.


              1. schors
                27.09.2015 13:19

                Причём тут опыт. Это тупо понятно из реализации. Нет ни урезанного проца (вот это видно сразу неворуженным взглядом на каком-нибудь «hello, world». ), ни перегруженной шины, ни затрат на диспетчеризацию всего этого (там какие-то вшивые максимум процентов 5%, но они кстати заметны). Нет жуткого оверкоммита на дисках, потому что 50 перлов запущенных в рамках одного контейнера совсем не тоже самое, что по 5 в десяти контейнерах тупо по чтению с диска. Поэтому при одинаковой суммарной нагрузке шаред заметно меньше потребляет ресурсов. Я регулярно перевожу сайты то с шареда на vsd, то с vds на шаред — очень заметно.


                1. XolodIT
                  27.09.2015 13:51
                  +1

                  Как же вас (нас) технорей сложно понять… наверное мы, почти, об одном и том же.


                  1. schors
                    27.09.2015 18:12

                    Да!!! :) Ну вообще по профилю понятно :)


        1. lexore
          27.09.2015 11:45

          В шаред хостингах любят устанавливать рамки потребления ресурсов.
          Нагрузка на cpu, объем памяти, количество процессов и т.д.


          1. schors
            27.09.2015 13:13

            Логично. Почему нет? Вы если сожрете на VDS все ресурсы, думаете будет лучше? Будет даже хуже.


            1. lexore
              27.09.2015 13:26

              Да не, все логично.
              Просто с шаред хостингом вам в лучшем случае пришлют сообщение, а в худшем просто отрубят.
              И это только cpu/load average.
              А ещё есть ограничение на память, количество процессов, количество открытых файлов и т.д.
              А с отдельным сервером вас никто специально вырубать не станет — хоть под 100% выжирайте.
              На своем сервере можно крутить sysctl, лимиты файлов, разные ядра, своп и т.д.
              Конечно, если нагрузка сильно попрет, нужно добавлять серверов и масштабироваться.
              Но тут уже все зависит от вас, а не от прихотей хостера.


  1. nikitasius
    25.09.2015 22:12

    Мде, кривая статья. Решил вставить свои 5 копеек про конфиги, затем про директории, затем про модули и плюнул к черту.
    nginx колосально гибкая система. Единственное неудобство — для добавления нового модуля надо остановить nginx, добавить модуль при компиляции, запустить сервер… все.
    Конфигурации на уровне папок, файлов, масок, регулярок — все все все легко или не очень, но настраивается.


    1. kemko
      25.09.2015 22:42
      +4

      для добавления нового модуля надо остановить nginx

      Зачем же останавливать? С древних времён в nginx есть механизм обновления на лету.


  1. lexore
    26.09.2015 01:04
    +8

    Вот вам практический взгляд на удобство конфигурации.
    В apache для виртуального хоста есть:

    • Directory
    • DirectoryMatch
    • Files
    • FilesMatch
    • Location
    • LocationMatch

    И у каждой директивы есть свои нюансики.
    Кто навскидку помнит, в каком приоритете они берутся?
    Чтобы точно знать, нужно постоянно сверяться с документацией.
    Кстати, забыли про If (а ещё Else и ElseIf).
    А так же, при проксировании директива Proxy становится вместо Directory.
    WTF?!?!?!image

    В nginx есть только location, у которой полно своих нюансов, но это это одна директива.

    Второй практический пример — директива NameVirtualHost.
    Допустим, у вас на сервере 1 ip адрес и вы прописали:
    NameVirtualHost 111.22.33.44:80
    
    Теперь будьте любезны каждый виртуальный хост указать, как
    <VirtualHost 111.22.33.44:80>
    

    А теперь сюрприз: «main server» и "_default_" виртуальные хосты сюда не попадут!
    В общем, дебильная система, слава богу, что её отменили с версии 2.3.11.
    Но в свое время она изрядно попортила мне нервов, когда я пытался понять, куда уходит запрос.

    В nginx все просто.
    Внутри блока server есть директивы listen и server_name.
    И все.

    И, наконец, htaccess и rewrite…
    Вы знали, что rewrite, кроме всего прочего, делятся на per-server и per-directory?
    И если посмотреть документацию, в конце описания RewriteRule, есть куча примеров, что работает только per-server, а что только per-directory.

    В nginx тоже есть rewrite и иногда он может заставить задуматься, но у него всего 4 флага и он ведет себе одинаково в любом месте конфига.


    1. xandr0s
      28.09.2015 10:51
      +1

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


  1. kelevra
    26.09.2015 06:54
    +1

    за перевод спасибо, но статья из разряда «капитан очевидность»: совместное использование не раскрыто. бывают ещё схемы в виде «много фронтендов nginx» и «мало бэкендов apache» за ними. используются там, где фактическая нагрузка на вебсервер не очень большая, но могут быть попытки dos/ddos. таким образом фронтенды из nginx принимают на себя основной удар, выполняя очистку трафика, а функциональность веб-сервиса при этом не страдает.


  1. achekalin
    26.09.2015 12:05
    +3

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

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

    Не говоря, что Nginx — это не только http(s)-сервер, но еще и почтовый прокси, например.

    Статья (перевод) объемная, и переводчику спасибо за нее. Что она пуста с точки зрения многих хаброжителей — увы, тут аудитория такую мякину не очень любит. Побольше бы конкретики, но это уже не к переводчику, а к оригинальному автору.


  1. XolodIT
    26.09.2015 19:50
    +1

    Выше прозвучали комментарии, что мол apache и шаред хостинги атавизмы, упомянули uwsgi и сделали круглые глаза… Но ребята из cpanel\ispmgr\vestacp\plesk не собираются закрывать офисы в отдаленной перспективе и тем более вводить поддержку этого. Вот вам и ответ индустрии по предоставлению как профессионального так и «местечкового» хостинга. Ну и ждем когда что-то затмит php и канут в лету движки с невероятной кучей реврайтов, возможно тогда что-то изменится.


  1. FSA
    28.09.2015 12:18

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

    Всё таки я укрепился в своём мнении, что apache мне не нужен. А если сделать так, как сказано, то совсем не вижу смысла даже думать от Apache.


  1. storm
    03.10.2015 14:16

    А кто-нибудь использовал такой продукт как Apache Traffic Server?
    Интересно сравнить, например, кеширование и проксирование на больших нагрузках в сравнении с nginx.


    1. baldr
      03.10.2015 14:23

      Быстрый гуглинг нашел презентацию, может быть будет вам полезной: http://www.slideshare.net/bryan_call/choosing-a-proxy-server-apachecon-2014


      1. storm
        03.10.2015 14:46

        ну она гуглится любым кто вобъет в строку поиска apache traffic server vs nginx
        Хотелось бы услышать про опыт реальных людей кто протестировал оба решения и сделал выбор в пользу продукта потому как…