Какую связку лучше выбрать Nginx+php-fcgi или apache+php-fcgi?
Какую связку лучше выбрать Nginx+php-fcgi или apache+php-fcgi? Какие подводные камни могут встретиться? Собираюсь перейти с апача на Nginx+php-fcgi и установить панель ISPConfig. Стоит ли?
@iDx, ну... из сложностей которые могут возникнуть на первых этапах со старыми CMS, которые до сих пор используют RewriteRule для "красивых ссылок", то придется все это переделывать под правила nginx-а. С другой стороны есть средства автоматизирующие данный процесс а так же не проблема найти уже готовый конфиг.
В целом же проблем каких-либо я не наблюдал. Есть кейсы когда пользователю нужны какие-то модули для apache, аналогов которых нету под nginx, но я если честно за последние года 4 не сталкивался с подобными задачами, либо были модули для nginx либо они и не нужны были.
Nginx, обычно используется как frontend, а apache как backend
Nginx создает пул потоков, которые обрабатывают входящие запросы (фиксированное число)
apache создает на каждый запрос по потоку. Так что тут php-fpm как то смысла не имеет.
Nginx хорошо отдает статику, может кешировать и т.д.
Можно поставить nginx и проксировать запросы к apache и кешировать результаты.
Как раз таки смысл есть уйти с апача на nginx+php-fpm. Apache каждый раз создаёт копию себя, тупо ещё один процесс, чем жрёт память и работает медленнее, чем php-fpm. Другое дело - надо тестить, будет ли с этим работать ваш ISP
@Calc не надо морозить чушь. Вы говорите про возможность Nginx работать как прокси. Тем не менее, это только одна из его возможностей. Это полноценный, быстрый и легкий сервер. Однозначно переходить, Apache в топку.
@HeadOnFire мне больше нравится воспринимать nginx как крайне эффективный фронтэнд, который может разруливать и проксировать на нужные бэкэнды очень много запросов. По сути это его основное предназначение - обрабатывать запросы и передавать бэкэнду. Ну и статику отдавать. Такой подход намного эффективнее того, что используется в Apache, который предпочитает весь функционал включать в себя (в виде модулей) и за счет чего падает производительность.
@Fesor все правильно. ИМХО, веб-сервер, по определению, именно это и должен делать - все что не требует обработки отдавать сразу, что требует - передавать на обработчик и отдавать результат. Обрабатывать запросы - это и есть главная задача. Плюс event-based, конечно же. Схема работы Apache, как по мне, уже устарела и не может быть эффективной. И уж тем более я не вижу вообще смысла использовать Nginx как фронт перед Apache. Зачем эта толстая прокладка, если Nginx сам может работать с PHP напрямую? К тому же, Nginx еще и напрямую работает с Memcached, а также имеет свой fastcgi кеш. Одни плюсы, в общем.
@Calc зачем? Все, что есть в .htaccess, есть и в nginx.conf / %site%.conf. Как говаривал один очень толковый системный архитектор, "большинство ваших запросов не должно доходить до БД, а в идеале - и до PHP". Зачем поднимать процесс Apache, если все уже давно можно было отдать клиенту без его участия?
@HeadOnFire Мы не в идеальном мире живем. А) зоопарк кода, B) зоопарк железа C) мы используем не только php, D) У нас нет доступа к /etc E) тупо mod_rewrite F) При создании процесса на задачу - производительность выше, нежели упихивать процессы в пулл, но не нужно злоупотреблять G) Вы сможете отличить пассатижи от плоскогубцев? H) habrahabr.ru/post/100961
@Calc А) править руки и мозги, потом код В) купить нормальный сервер С) Nginx отдает на самые разные бекенды и забирает от них D) см. п.B или дергаем одмина Е) реврайты в Nginx есть, при чем толковее F) это какие-то синтетические тесты и абстрактная теория, в реальности же на среднестатистическом VPS с 0.5-2Гб оперативы и 1-2 виртуальный ядром Apache никогда не будет быстрее Nginx, кроме того, он не выдержит даже небольшой нагрузки. На коробках с большими ресурсами поначалу разница незаметна, но она всплывает, как только растет количество конкурентных запросов - и все повторяется G) Да, это разные инструменты, выглядят по-разному и работают тоже H) Бородато. Такие конфиги на обработку .php сейчас еще кто-то ставит? Пост 2010 года.
Средний
