Apache против Nginx. Apache есть место в 2019м? Сравнение двух лидирующих HTTP серверов

В прошлом выпуске мы поднимали старый добрый ламповый сервер на Debian — Linux, Apache, MySQL, PHP. В комментариях кто-то написал, что настраивать Apache сейчас это моветон и вообще Apache отстой. Так ли это на самом деле?

Разберём особенности работы этих двух популярных HTTP серверов, проясним сильные и слабые стороны и выясним, в каких задачах имеет смысл выбрать Nginx, в каких — Apache.

0:00 Apache умер?
1:20 Статистика использования веб-серверов в WWW
1:55 Как работают с HTTP соединениями Apache?
4:21 Как работают с HTTP соединениями Nginx?
6:14 Как работают со статическим и динамическим контентом Nginx и Apache?
8:34 Htaccess файлы
11:13 Резюме по сравнению Apache vs Nginx

/****************** about ******************/

Меня зовут Алексей Голобурдин, я программирую с 2004 года и на этом канале делюсь своим опытом. Я основатель и руководитель компаний:

[ВладБонем]

Идеально рассказано, без воды.
Всю нужную информацию вместил в 13 минут, у некоторых это занимает час.
Спасибо, за такое лайк!

[den]

Очень толковое видео, без воды, по полочкам все красиво разложил!)

[tdigital]

Вообще сам лого Apache, это перо — вызывает у меня чертовскую ностальгию:) 2004й, я в 11м классе, первая книга по веб-технологиям, тонкая такая брошюрка в мягком переплёте, рассказывающая, как поставить Apache на Windows и прикрутить туда PHP 3й или 4й версии. Это всё тогда, конечно, было просто космического, крышесносного уровня магией, захватывающей и интересной. Интернета почти не было — по модемным карточкам, которые стоили 60 руб за, если не ошибаюсь, пол часа доступа к сети, которых никак не хватало, чтобы хоть что-то оттуда выцепить. Да и 60 руб это была сумма тогда. Дааа:)

Не могу не улыбнуться, вспоминая то время:) Может видос отдельный про это снять?

[philz]

самый недооцененный тек блогер в мире...

[UserUser-bctc]

Спасибо за простое и информативное объяснение, продолжай в том же духе!

[ВикторКозлов-гб]

Благодарю! Снова всё, наконец-то, уложилось по полочкам в голове. Алексей, у вас великолепно получается подавать материал! Величайше благодарю за всю вашу работу!

[alextokt]

Спасибо большое за ваш вклад, все оч нравится, не прекращайте это дело, все круто, всех благ

[Vardakakash]

все видео из головы не лез вопрос: так все же вебсарвар или апликейшенсарвар. :D


как всегда, прекрасные объяснения, спасибо

[zorky]

Отличное видео, поддерживаю такой же формат про субд

[myhomework]

Если в вопросе скорости, то как помню, как раз mod_php для apache самое быстрое решение. Но оно обладало огромным (для некоторых случаев) недостатком это невозможность разделение ресурсов по пользователям. Все скрипты выполнялись от имени владельца apache, и пользователи могли свободно шариться по соседним каталогам.
Как раз FastCGI решило это проблему, но за счет некоторого снижения производительности ввиду необходимости стартовать новые процессы (php-cgi), а не выполняться в уже запущенном apache.
Nginx со своей асинхронностью привнес снижение нагрузки на железо, более шуструю работу со статикой, соответственно появилась возможность обслуживать большие нагрузки. Его часто стали ставить на фронт перед апачем. Он отрабатывал статику и проксировал php на апач, а тот в свою очередь на FastCGI. Проблема htaccess уже тут начала вырисовываться. Так как от апача было бы интересно отказаться, но очень много CMS тогда использовали htaccess (собственно и сейчас так, но именно сейчас крайне много информации по переносу htaccess на правила nginx и это уже не вызывает сложности, так же панели управления серверами научились автоматом вставлять эти правила в конфиг nginx).
Могу ошибаться, но вроде бы быстро fast-cgi сменился на php-fpm. Это повысило скорость выполнения php и, опять же на сколько могу помнить, сравнялось по скорости с модульным php. Но при этом оставалась возможность выполнять скрипты от имени владельца. После этого апач стал ну вообще ни при делах. Оставалась только загвоздка с htaccess, но, если это был не сервер шаред хостинга, то решалось однократной настройкой на этапе установки ПО и запуска сайтов.
Варианты с версиями php для apache были и ранее, помню были шаблоны конфигов которые по расширению файла выбирали версию модуля для обработки. В этом случае дописывалась версия php после расширения файла, например, index.php5. С переходом на FastCGI задача выбора версии PHP вообще сильно упростилась и до сих пор не является чем то сложным.

[darkmitya]

Вообще к пониманию статистики веб-серверов стоит учесть, что чаще всего в highload проектах, то чаще всего идет nginx как frontend прокси для статики и балансировщик для нескольких apache, которые идут backend`ом. И в целом nginx все же чаще используется именно как проксирующий сервер, и это относится не только к понятию web-сервер

[vladsered]

Делаю вклад в комюнити Apache, и вы знаете меня постоянно поражает стереотип о сравнении nginx Vs apache.
И я могу с уверенностью сказать что Apache есть место и в 2020 году, да и в будущем тоже.
Но вот мой ответ на стереатипное утверждение что apache не для highload.
1. Не секрет что у apache есть те же самые воркеры в mpm modules, возьмите mpm_event настройте, и будет такой же функционал воркеров-потоков.
2. Так же не секрет и поддержка php-fpm в apache, а в конфигурации fastcgi, php-fpm(UDS), apache обходит nginx по скорости выполнения скриптов, даже unity режим nginx'a обходит.
3. Этого еще нет в оф релизе apache, но это уже заложено в исходники apache, поддержка PCRE2, что может говорить нам об улучшения в производительности apache модуля Rewrite который отвечает за работу htaccess. Я даже написал статью по этой теме на хабре, Как сделать поддержу PCRE2 в Apache 2.4.
4. Финальный момент для статики положительно будет поддержка Pcre2, Ну и конечно поддержка HTTP 2.0 принесет скорость обработки запросов, и статики в том числе.
С такой конфигурацией можно забыть о стереатипах стекла веб сервера, и идти в будущее, в ногу со временем.
Интересно будет увидеть цитату автора ролика к этому комментарию.

[fanfanius]

Привет, коллега. Классный контент, подпишусь на канал. Я не согласен с тем что apache настраивается легче чем nginx, как по мне второе намного легче, и документация более понятная. И ещё ты не упомянул о куче модулей для nginx и о возможности расширении функционала с использованием lua

[flatmapper]

мне казалось, что keep alive указывает, что tcp соединение должно висеть, а не http

[openmanerror]

чётко, толково, коротко и по существу
подписываюсь на канал, жму колокольчик и лайк :)

[osvaldsozolnieks]

Спасибо, давно хотел себе именно это разъяснить.

[cannibalirk]

Оч крутой видос!) Хорошо, что я знаю что такое процесс, поток, асинхронная обработка запросов и application-server))
Кстати, по поводу конфигов. Получается, что Apache считывает htaccess каждый раз, а Nginx считывает один раз и держит эту информацию в оперативной памяти?
Интересно кстати, что получится если сравнить NginX и какой-нибудь сервер на платформе Node.js.

[horlonangel]

Однажды меня заинтересовал NGINX. Рекламировали, что держит большой трафик посещений... Повелся и попробовал. На счет того, что NGINX тянет высоконагруженные сервисы, а Apache нет или же ему это делать тяжелее, это же брехня. Да NGINX легче чем Apache и на небольших нагрузках разница есть. Но только начинаешь грузить по-сильнее, как разница по-тихоньку "уходит в туман". Есть, конечно же, сугубо частные случаи, но они не всчет. В сравнении с Apache, какой-то разницы в потере производительности не заметил. ~1500 запросов в секунду перед тем как сервер с Apache начал захлебываться, сервер с NGINX лег где-то уже после 1000. Нагрузка поднималась экспоненциально. В добавок Apache может намного больше. А на высоко нагруженных сервисах можно использовать FastCGI и сэкономить ресурсов дополнительно (если вы разрабатываете эти сервисы). На счет того, что Apache не может работать с двумя версиями PHP... И ты не можешь назвать профессионалами людей, которые не умеют работать с обоими (NGINX и Apache) серверами? Я лично поднимал сервер, который работал и с PHP5, PHP7 и Python... Просто нагуглил и ради интереса поднял. Было несколько лет тому назад, вспомнить тяжело, но принцип работы такой: задаются условия и указывается модуль *.so, который будет обрабатывать запрос. Этим методом можно обработать скрипт, практически, на любом языке (с оговорками, конечно). Да, это костыли, но по-другому никак и даже в NGINX... PHP (5 или 7) и Python использовать еще можно, но PHP5 и PHP7 одновременно использовать без боли и слез уж никак (да и не знаю где это нужно вообще, на хостинге разве). Я уже молчу про пляски с одновременной установкой их на один сервер. Проксировать запросы это просто фигня полная. Как это можно записывать в положительные качества не понимаю. Это просто есть по-умолчанию (такое можно написать на коленке для любого сервера), да и как оно проксирует? Костыли же...

[loam]

Хороший канал, судя по всему, подпишусь.

[neins]

Я так и не понял что не может делать хорошо nginx то что может делать apache? В чем преимущество для nginx в данной связке?