Профит от nginx как фронтенда перед apache

Падает, потому что криво настроил.

Настраивал не я.

Но апач - не лучшее решение для фронтенда насколько я знаю. Вот и хочу понять плюсы и минусы решения

Падает именно апач? Профита не будет.
1000 запросов на один инстанс апача - это много. Что за апачем? Падает даже если на статический контент нагрузку пускать?
Вообще апач же кучу воркеров создает, надо их количество и число соединений на один воркер тюнить, потому что если их не хватает, то будет падать, или может OOM'ом убиваться, если в память упрется.

Но апач - не лучшее решение для фронтенда насколько я знаю.

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

Та просто nginx фронтендом перед apache со статикой через nginx более лучшее. Меньше потребление памяти на коннект, более лучшее работа с медленными клиентами, шустрее. Но да — apache подтюнить тоже стоит.

Падает именно апач?

Падает SSL на апаче.

1000 запросов на один инстанс апача - это много. Что за апачем? Падает даже если на статический контент нагрузку пускать?

Сложных тестов не запускал пока - банальный apachebenchmark на https://servername.com/index.html

Вообще апач же кучу воркеров создает, надо их количество и число соединений на один воркер тюнить, потому что если их не хватает, то будет падать, или может OOM'ом убиваться, если в память упрется.

Посмотрю, спасибо за наводку

Смотря что за ним. Если php - то профита от php-fpm много не будет

да ладно? а мужики то и не знают. по мне php-fpm сильно веселее чем php через апач работает.

а вообще связка php-fpm+nginx+apc способна держать оч хорошую нагрузку, а если varnish запилить то вообще сказка будет.

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

Если php

php

а возможностей конфигурации очень много потеряешь.

На apache или nginx?

Ну и дык ssl через nginx и все путем.

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

Да.

Сейчас этим занимается сам апач.

а вообще связка php-fpm+nginx+apc способна держать оч хорошую нагрузку, а если varnish запилить то вообще сказка будет.

То есть апач прочь совсем?

То есть апач прочь совсем?

если ожидается хорошая нагрузка, то я бы убрал + nginx и php-fpm нужно нормально настроить.

Например такая конструкция в конфиге достаточно существенно увеличивает скорость отдачи статичного контента -

location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js|mov)$ {

                expires 14d;

                access_log off;

                log_not_found off;

                break;

        }

ну и в том-же духе :)

а возможностей конфигурации очень много потеряешь.

Например? Перешёл давеча на nginx+php-fpm и я вам скажу что мне нравится это.
Из минусов только то что nginx не умеет запускать воркеров для vhost-ов под разными юзерами, в конфигурации с несколькими сайтами это удобно.

nginx может сохранить ответ от бекенда в буфере в памяти чтобы отдать медленному клиенту. Апач в отличии от nginx будет воркер с php держать живым, пока последний байт не отдаст.

Пример: apache держит 1000 коннектов с ноды, запрос выполняется за 50 миллисекунд, ответ отдаётся клиенту за 400мс. Максимальная скорость будет 2500 запросов в секунду. Это без keep-alive, с keep-alive всё может ещё раньше сдохнуть

nginx держит 100-500к конектов с ноды, Keep-Alive уменьшает время отдачи результатов, т.к. операция connect в https очень дорогая. Nginx упрётся в 10-20k запросов в секунду.

Разница по скорости работы между nginx+php-fpm или nginx+apache/mod_php на уровне погрешности на реальных тестах. php-fpm экономит память, на 4GB RAM серверах будет больше инстансов.

Если это AWS, то можно заставить шифрованием заниматься «AWS Elastic Beanstalk Environment»

То есть апач прочь совсем?

+1

Например файлы .htaccess, что в случае шаред хостинга обязательно, потому что клиенты взбунтуются. Ну и про воркеров с разными юзерами - да, тоже нужно. + апач умеет modsecurity, которого в виде, готовом для продакшна, нет в nginx (а в php modsecurity тяжко, т.к. большинство cms на php - адовое решето). Ну и прочие специфические вещи.

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

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

во поводу воркеров - обычно php-fpm раскидывается по разным юзерам.

php-fpm да, а сам nginx нет. Прихозится совершать некоторые дополнительные телодвижения что-бы работала схема по пользователю на сайт. Хотя если права на файлы chmod o+r (оно так по умолчанию) то вроде и без дополнительных телодвижений должно работать. Но это попахивает решетом, получив шел (поломав сайт А) можно получить логины и пароли для БД остальных сайтов, что зачастую позволят получить шелы у тех пользователей от которых те сайты работают (и напихать вредоносов во все сайты).

P.S. при инклюде нельзя ограничить параметры которые может определять пользователь, в апачёвом .htaccess — можно (вроде только частично).

Но в общем-то .htaccess действительно нужен только для шаред-хостингов, да и там в принципе можно придумать альтернативы, просто «пацаны не поймут».

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

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

но чтоб грамотно всё настроить, это знатно упороться нужно. да.

P.S. при инклюде нельзя ограничить параметры которые может определять пользователь, в апачёвом .htaccess — можно (вроде только частично).

Но в общем-то .htaccess действительно нужен только для шаред-хостингов, да и там в принципе можно придумать альтернативы, просто «пацаны не поймут».

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

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

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

Если любой пользователь может читать файлы сайта (chmod o+r), по умолчанию оно так для всех файлов то nginx сможет получить доступ к файлам сайта без дополнительных телодвижений. Но это решето, потому-что смотри выше.
Можно например добавить пользователя nginx в группы всех сайтов, но это жополнительные телодвижения (до которых ещё не всякий одмин догадается, особенно если всё и так искапорки работает).

у меня на пачке серверов шаред сайты, пару раз только возникали проблемы

В некоторых похапэ скриптах доступ «куда неположено» закрывается файлом htaccess. Без обработки этих файлов всё будет работать и скорее всего никто ничего не заметит, но будет открыт доступ к чему-то что разраб считал недоступным для посетителей.

Конечно веру в то что htaccess используется всегда нельзя назвать лучшей практикой, но что уж тут поделаешь.

В некоторых похапэ скриптах доступ «куда неположено» закрывается файлом htaccess. Без обработки этих файлов всё будет работать и скорее всего никто ничего не заметит, но будет открыт доступ к чему-то что разраб считал недоступным для посетителей.

о дааа, видел пару раз говноCMSки где авторизация идет через htpasswd. ну и всякий ад типа конфигов с паролями к бд в виде .txt тоже.

Если любой пользователь может читать файлы сайта (chmod o+r), по умолчанию оно так для всех файлов то nginx сможет получить доступ к файлам сайта без дополнительных телодвижений. Но это решето, потому-что смотри выше.
Можно например добавить пользователя nginx в группы всех сайтов, но это жополнительные телодвижения (до которых ещё не всякий одмин догадается, особенно если всё и так искапорки работает).

если админ не вникает полностью в свою работу - гнать его нужно метлой :) жалко что не все это понимают.

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

Подробнее можно?

Подробнее можно?

adduser nginx web-example-com
nginx — пользователь под которым работает nginx
web-example-org — пользователь (и одноимённая группа) под которой работают php-fpm воркеры сайта exapmle.org (конфиги пулов воркеров хранятся в /etc/php/fpm/pool.d/ или вроде того).

Команда добавляет пользователя nginx в группу web-example-org.

На файлы скриптов устанавливаются права вроде 760 или 740 (rwxrw---- или rwxr-----). Владелец и группа: web-example-org.

Похаповые воркеры могут сделать с файлами что угодно (потому-что работают из-под пользователя web-example-org который владеет файлами), nginx может их читать-писать (или только читать, во втором варианте) потому-что входит в группу которой принадлежит файлы (в неё-же можно включить пользователя (человека) обслуживающего сайт).

Но есть проблемка: если пользователь vasya зальёт на сайт новые нескучные иконки то принадлежать они будут пользователю vasya и группе vasya. И если у Васи установлена umask вроде 007 то nginx не сможет прочесть эти новые иконки и будет выдавать посетителям вместо них forbidden. В случае более либерального umask кулхацкер поломавший соседний сайт сможет невозбранно стырить иконки. Иконки-то не жалко, но ведь это могут быть не только иконки.
Несколько помогает setgid бит на директории в веб-руте сайта, но периодически всё-же приходится бить себя ладонью по луб со словами «а владельца-то поменять забыл!»

если админ не вникает полностью в свою работу - гнать его нужно метлой :) жалко что не все это понимают.

Многие вообще не задумываются о том что сайтов на сервере может быть больше одного (в смысле до того момента когда понадобится добавить второй сайт). Да и зачем что-то там костылять когда и так всё работает? (: Проблем-то никаких нет. В смысле таких проблем которые может заметить (и погнать админа метлой) непосредственное начальство/заказчик.

А если (в смысле «а когда») один из сайтов поломают и загядят малварью, а вмести с ним и прочие... Ну что, поломали сервак, что уж тут поделаешь? Это всё вордпрес кривой виноват, и отдел разработки, и евреи.

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