Debian.pro

Блог для пользователей и администраторов Debian


Большой мануал: часть 15. Ставим пакеты для lamp+nginx.

Эта статья — часть Большого Мануала по настройке lamp-сервера на debian.

Предыдущая часть цикла — Получаем ssl-сертификат. Letsencrypt в массы.

Следующая часть цикла — Подготавливаем nginx.

Вот мы и подошли к установке веб-сервера на наш сервер. 14 частей мануала до этого мы наш сервер приводили в божеский вид =)

Для начала я постараюсь избежать некоторое количество холиваров. Существует 2 «секты» php-ников. Первые используют php-fpm и на каждом углу кричат, какой он быстрый и клёвый, а апач большой жирный и медленный. Вторые не парятся и используют апач.
Да, мы будем настраивать связку nginx+apache+php. Да, в 2016м (2017м, 2020м — подставить нужное) году. Почему? Да легко. Самое важное — для нормальной настройки сервера с nginx+php-fpm вы должны _понимать_ что вы делаете. Досконально. Вы не должны путаться в конфиге nginx, вы должны написать конфиг для fpm-пула именно для вашего случая, вы должны уметь написать соответствующий конфиг nginx. Есть, конечно, хорошие мануалы (и у меня здесь один валяется и на хабр я помогал такой писать), но проблема в том, что в случае с fpm метод копи-пиздинга не работает. В лучшем случае вы просто не сможете написать конфиг nginx для вашей очень редкой CMS и работать ничерта не будет, в худшем — вы тупо получите черную дырку, вместо какой-никакой безопасности сервера. Если вы всё это понимаете — то просто не читайте те части мануала, которые касаются апача.

Есть поверье о медлительности и прожорливости апача. Да, он кушает ресурсов больше, чем fpm. Он кушает больше оперативной памяти. Но сейчас даже у кофеварок есть 1гб памяти, а полному стеку лампы хватит и 512. Да, апач отвечает немного медленнее. На 0.2 секунды где-то при прочих равных. Вам оно так важно? Перейдите на ssd, php станет интерпретироваться в 2-5 раз быстрее (а под апачем или под fpm — уже не важно будет). Кстати, весомая часть времени работы апача (без учета самой интерпретации php) уходит на поиск .htaccess-файлов и их обработку, можно отключить работу с ними — станет быстрее (содержимое htaccess можно перенести в конфиг вхоста, это всё ещё проще, чем перенести их в конфиг nginx). А для экономии памяти можно повырубать ненужные модули. И, кстати, апач 2.4 пошустрее своих предков. Ах да, если сайтов много, но туда почти никто не ходит — то апач выгоднее. Апач держит пул процессов под все сайты (допустим, 10 процессов), а в fpm нужно создавать (по уму если) отдельный fpm-пул для каждого сайта — а это, как минимум, 1 запущенный процесс на каждый сайт (даже на сайт с посещалкой в 2 челочека в месяц), что уже совсем не экономит память.

Но есть случаи, когда вам действительно нужен fpm. Навскидку:
- у вас какое-нибудь api, которое отвечает за время, сравнимое с тем временем, которое apache тратит на накладные расходы. Допустим, за 200мс и меньше. Если речь про сайт, в который пользователи штырят браузером, то повторюсь — куда больший прирост скорости загрузки сайтов даст ssd + всякие cdn-ы + грамотная верстка (даже если страница сайта изначально генерится за 200 мс, то до пользователя она целиком всё равно ехать будет полсекунды-секунду). Сэкономить 50-100мс из секунды, но нажить себе геморроя?
- у вас действительно мало памяти (мегабайт эдак 192), а запустить php там надо.
- у вас большой RPS. После 50 RPS по секунде апач начинает отжирать ресурсы чуть ли не по экспоненте, и где-то к сотне запросов в секунду (каждый из которых занимает процесс апача на секунду) начинаются видимые проблемы. Ну то есть php-fpm с сотней активных запросов будет жить лучше, чем апач с сотней активных запросов в php (только не путайте «активный запрос в web-сервер» и «открытая загруженная страница в браузере, в которую пользователь штырит»). Впрочем, всё зависит от кода — на хорошем коде апач выдаёт 500 RPS и не жужжит.

Вообще же для сравнения nginx+php-fpm и nginx+apache по скорости важно понимать, что сравнивать нужно не время генерации страницы сервером, а время рендеринга страницы на клиенте со всем дерьмом (хендшейк, скачать всю статику, выполнить js, подгрузить внешние скрипты-шрифты-etc, построить DOM-дерево и, собственно, отрендерить). Проще говоря, нужно сравнивать не «апач генерит страницу за 0.3с, а fpm за 0.15с», а «с апача браузер отрисует страницу за 1.8 секунды, а с fpm — за 1.65″. Согласитесь — во втором случае разница уже не так страшна и не всегда окупает необходимость поработать лапками.

Ладно, это всё лирика. Вообще эта часть мануала достаточно короткая, сейчас мы просто поставим пакеты. Напомню, что mysql мы уже поставили и настроили.
Ставим пакеты:

root@server:~# apt-get -qq update; apt-get install apache2 apache2-mpm-itk apache2-utils apache2.2-bin apache2.2-common libapache2-mod-rpaf libapache2-mod-php5 php-apc php5 php5-cli php5-gd php5-mcrypt php5-mysql php5-curl php5-imagick php5-intl

Если вы уверены, что php-модули вы можете потом поставить сами (и сами поймете, какие нужны), то лучше так:

root@server:~# apt-get -qq update; apt-get install apache2 apache2-mpm-itk apache2-utils apache2.2-bin apache2.2-common libapache2-mod-rpaf libapache2-mod-php5 php-apc php5 php5-cli php5-mysql

Перед установкой nginx-а, нужно стопнуть апач:

root@server:~# /etc/init.d/apache2 stop

или

root@server:~# apachectl stop

Ставим nginx:

root@server:~# apt-get install nginx

Мы поставили nginx, apache в режиме mpm-itk (такой режим позволяет запускать каждый vhost от отдельного пользователя, на тот случай, если вам нужно хостить какое-нибудь дерьмецо вроде битрикса), разные пакеты для работы php (часто используемые модули и, собственно, интерпретатор php + плагин к апачу для запуска php).

В следующих статьях мы будем медленно, мучительно и внимательно настраивать всё это.

27.05.2016 byinkvizitor68sl|big-manual

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

  1. Максим :

    Я сравнивал связки LAMP+Nginx (apache через php-fpm) от serverpilot.io и LEMP от easyengine.io на одной и тойже vps ssd, один и тот же сайт. Без кеширования и допиливания, установил стек, развернул сайт, запустил тест.

    Первый стек (Nginx+Apache+PHP-FPM):
    wrk -t12 -c100 -d60s http://185.143.172.11/wp1/
    Thread Stats Avg Stdev Max +/- Stdev
    Latency 1.33s 430.10ms 1.80s 61.90%
    Req/Sec 3.49 3.57 20.00 81.87%
    1339 requests in 1.00m, 41.54MB read
    Socket errors: connect 0, read 0, write 0, timeout 1318
    Requests/sec: 22.28
    Transfer/sec: 707.74KB

    Второй стек (Nginx+PHP-FPM):
    wrk -t12 -c100 -d60s http://example.com/
    Running 1m test @ http://example.com/
    12 threads and 100 connections
    Thread Stats Avg Stdev Max +/- Stdev
    Latency 60.25ms 34.42ms 1.27s 97.55%
    Req/Sec 98.20 38.27 232.00 65.64%
    59693 requests in 1.00m, 35.45MB read
    Socket errors: connect 0, read 0, write 0, timeout 151
    Non-2xx or 3xx responses: 59564
    Requests/sec: 993.49
    Transfer/sec: 604.25KB

    Я не особо в этом всем разбираюсь, поэтому хотелось услышать комментарии эксперта :)

  2. > 59693 requests in 1.00m, 35.45MB read
    > Non-2xx or 3xx responses: 59564

    Вот 2 строчки, на которые нужно смотреть. php-fpm упал почти сразу, а уже страницу с надписью 502 bad gateway nginx может отдавать сколько угодно раз в секунду.

  3. Максим :

    Ох, слона то я и не приметил.
    А что скажете по поводу подключения php к apache через php-fpm, а не через классический mod_php ?

  4. > А что скажете по поводу подключения php к apache через php-fpm, а не через классический mod_php ?

    Бессмыссленная затея, htaccess и другие «динамические параметры» (или как их там называют, я уже забыл) работать не будут, а без них апач в целом действительно не нужен.

  5. stas :

    Здесь надо учесть, что апач поставлен на предыдущих шагах, перед установкой nginx надо его остановить

  6. Я потом статьи в правильном порядке раскидаю.
    Но так да.

  7. В общем, поправил пока статью, а там разберусь, если не забуду.

  8. drcrazy :

    В Stretch по умолчанию PHP7. Стоит насильно ставить PHP5?

  9. > Стоит насильно ставить PHP5?
    От задачи зависит.

    Под stretch я пока не начал переписывать статьи.

Написать комментарий