Зачем нужен nginx когда есть апач?

> Добрый день, хотел узнать, а зачем нам proxy, какой в нем смысл, если это не шлюз
> The Web Proxy Server (Nginx) service on host xxx.com has been started on Jan 22, 2016 04:07 PM.

Все, что ниже написано, не точное полжение вещей — для понимая многие вещи существенно упрощены. Зато с картинками 🙂

На сервере 16Г памяти, вроде, достаточно много. Но:
— ядру для более-менее нормальной работы нужна память. Пусть это будет 1Г, всетаки сервер..
— смотрим сколько может скушать mysql. Запускаем /home/mymysqltuner.pl, смотрим строку:
[OK] Maximum possible memory usage: 10.9G (71% of installed RAM)
итого, mysql, при определенном стечении обстоятельств, может скушать почти 11Г памяти.
— у нас на сервере есть:

  • панель управления, несколько процессов;
  • monit — панель им пытается контролировать запущенные службы;
  • named — ДНС;
  • sshd — для доступа к серверу по ssh;
  • postfix — почта, оправка-прием;
  • courier-pop3d — почта, работа с клиентами;
  • courier-imapd — почта, для доступа по протоколу imap;
  • spamd — болрьба со спамом;
  • clamsmtpd — проверка почты налету;
  • freshclam — демон, контролирующий актуальность баз антивируса clamav;
  • периодически запускается clamav для проверки папок с сайтами;
  • munin-node — клиент munin;
  • fail2ban — написаный на python;
  • некоторые другие службы, которые я ненамеренно упустил.

Естественно, что всем им нужна память, которой после ядра и mysql осталось уже не так и много.
А теперь, собственно, о nginx и апаче. Смотрим картинку:

nginx_status-day

и обращаем внимание на «Active connections», колонку MAX. У нас вчера было 5 минут (munin усредняет за 5 минут) когда, в среднем, было активно почти 70 соединений сервера с клинтами. Представим, что nginx перед апачем нет, и все 70 соединений держит апач. Сколько памяти для этого нужно?
Запускаем top и смотрим, сколько памяти может потреблять один чайлд апача:
 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 2797 apache    30  10  722m 199m  36m S 43.2  1.3   0:04.54 httpd

То есть, у нас есть процессы пача, потенциально потребляющее до 200М памяти. 200М * 70 = 14Г. Естественно, на самом деле будет несколько меньше, мы же взяли для расчета максимальное значение. Но, если меньше будет даже в два раза, то 7Г свободной памяти у нас уже нет! Следовательно, система начнет в качестве памяти использовать swap, и, как говрят, «станет раком» — процессы начнут выполняться в стри раз медленнее, что приведет к лавинообразному увеличению количества процессов, что в свою очередь, еще замедлит их выполнение. И так по кругу.

Логичный вопрос: а сколько памяти использует на одно соединение nginx?
При настройках по умолчанию — 32К.
В гиге памяти буде, грубо говоря, 5 соединений, удерживаемых апачем и, без малого 33000 соединений, удерживаемых nginx.

Реально, скролько вчера было одновременно активных процессов апача? Смотрим:
apache_processes-day
«basy serrvers» MAX — 4.91

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

Дальше просто перечень других причятных вещей:
— nginx умеет сам отдавать пользователю статические файлы (картинки, стили, джаваскрипты) вообще не обращаясь к апачу, причем, эффективнее, чем это делал бы апач;
— в nginx легко настраиваются ограничения которые полезны для защиты от простых атак, типа: количество одновременных подключений с одного ip, скорость запросов с одного ip. В апаче это тоже можно сделать. Для этого нужно ставить нестандартные модули, а  в nginx это есть с коробки. Причем, делать такие ограничения апачем часто не имеет смысла, поскольку памяти ему нужно «чуток» больше.
— есть виды атак, от которых у апача вообще нет защиты, например «атака медленного чтения». Вряд ли монстр в лице mod_security можно считать защитой. А у nginx — защита легко настраивается стандартными средствами.
— многое другое, чего сходу и не вспомню.

Естественно, у nginx есть и минусы, но сегодня речь не о них.

В качестве вывода: связка nginx + apache давно стала классикой жанра 🙂

 

Запись опубликована в рубрике Вопросы - ответы. Добавьте в закладки постоянную ссылку.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *