Apache + nginx. Возможные проблемы

Question

[netherneon]

На данный момент есть куча сайтов на одном сервере, работающих на linux, apache 2.2.x mod_php, mysql. В связи возрастанием нагрузки есть мысль поставить перед этим делом фронтендом nginx. Подскажите кто делал подобное, какие есть подводные камни? Есть ли шансы что на каких то сайтах могут отвалится ajax'ы comet'ы .htaccess'ы или что то еще? Заметят ли как то изменения владельцы сайтов и разработчики. Буду благодарен за любую информацию, заранее спасибо.

Answer 1

[zizop]

Существует два метода подобного рода миграции.

1. Поставить Nginx перед Apache. Тут в принципе всё просто. Статику (картинки, js, css и т.д.) раздает Nginx, динамику (php) проксирует на Apache. Подводные камни: правильное разделение контента на статический и динамический, отключение логгирования для статики, выставление правильного времени кэширования.

2. Отказаться от Apache полностью в пользу Nginx. Потенциально дает больший прирост производительности. Лучше выполнять постепенно, после 1го метода. Подводные камни:
придется переписать .htaccess на директивы Nginx. Для популярных движков типа Joomla, WordPress это уже сделано, в других случаях придется курить регэкспы. mod_php скорее всего придется заменить на php5-fpm, тут вроде ничего сложного. По поводу comet'ов надо будет поставить http_push_module для nginx. Всё, кроме последнего недавно сам прошел, производительность здорово подросла. Немало в этом помогло подключение memcached к nginx, в разряд статики перешли динамические странички, закэшированные для гостей.

Comments

[DevMan]

mod_php скорее всего придется заменить

Не скорее всего, а однозначно :)

[andoriyu]

Ну можно еще заменить на php-fcgi через spawn-cgi.

Answer 2

[odmin4eg]

Сам чёрт намного красивее чем кажется. самый простой вариант это разделить на фронт-энд и бэк-энд

я давненько для себя писал инструкцию
www.odmin4eg.ru/2008/nginx-na-ubuntu-prosto/

Но суть её сегодня не изменилось, только нудно скачать свежий nginx с оф сайта, собрать его ( www.odmin4eg.ru/2009/nginx-na-ubuntu-eto-prosto-kompilyaciya/ )
и запустить.

по тойже схеме всё у меня работает до сих пор отлично, просто и надёжно.

потом появился сайт, что был намного тяжелее всех остальные при этой же схеме его стал обрабатывать php5-fpm
а все остальные как и раньше продолжали работать на apache
( www.odmin4eg.ru/2010/pereezzhaem-na-php5fpm/ )

Answer 3

[unnamed]

Все будет хорошо, но есть особенности:

Из коробки — в скриптах и логах апача будет ip адрес фронтенда а не юзера, читайте например здесь www.lexa.ru/srch/?text=rpaf§ion=6&sort1=rl

В апаче нужно KeepAlive Off

Comments

[SwampRunner]

почему KeepAlive Off?

[Пума Тайланд]

Потому что это сделает за вас нгинкс

Answer 4

[gaelpa]

Подводные камни в пхп-скриптах видел такие:

• При использовании $_SERVER['SERVER_NAME'], $_SERVER['HTTP_HOST'], $_SERVER['SERVER_PORT'] будут отображаться данные apache-бэкэнда, т.е. может вылезти ерунда, если эти переменные используются в выводе
• При использовании $_SERVER['REMOTE_HOST'] и $_SERVER['REMOTE_ADDR'] будут выдаваться данные nginx-фронтжнда

Comments

[YourChief]

со вторым борются посредством mod_rpaf для апача

[YourChief]

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

[zizop]

В nginx вроде можно пробрасывать параметры или перезаписывать их.

[Пума Тайланд]

Не ставьте мод рпаф он кривой, не работает на хтакцесах например, ставьте mod real ip 2 он корректно везде работает.

Answer 5

[Horse]

Предложу другой вариант. Nginx поставить рядом, на 81-ый порт.
В таком случаее легко можно будет указывать, что есть статика, ничего не нужно проксировать, работает быстрее, полностью отсутствуют подводные камни (если конечно-же 81-ый порт открыт) )

Comments

[netherneon]

Как это будет работать? Заходит юзер на 80 порт, там апач и что происходит дальше?

[Horse]

Апачт генерит html в котором будет не

[Horse]

Сорри. покушал код хабрадвижок.

Апачт генерит html в котором будет не

а


В таком случаее браузер будет направлять запросы на получение статики уже на 81-порт, на котором висит nginx.

Все очень просто в реализации, особенно если есть в коде константы типа
image_folder_url
script_folder_url...
Нужно будет просто поставить nginx, уазать порт и папку.
добавить статике :81 и все будет работать как часы.

[Horse]

Блин, опять…

[Horse]

upload.utcit.com.ua/upload/45e7e0a6591d2adf6879d03bcbcf3a75%20(2011-03-18%2017:19:55).html

[pentarh]

Вешать веб сервак на нестандартный порт плохо. Для больших сайтов. Офисные админы иногда блокируют левые порты юзверям.

[Horse]

Руки отрубить им за такое надо. Ну в идеале веб-сервак не должен быть в локальной подсети с офисными компами… И офисные админы не должны закрывать порт, не зная зачем он используется.

[Anastasia_K]

Много где используются транспарентная прокся. Перевешиванием статики на 81 порт Вы лишите офисного пользователя прелестей кеширования. Да и закрытие нестандартных портов используется гораздо чаще чем Вы думаете.

[Владимир Чернышев]

Вы кажется не поняли кто и что блокирует. Есть ваш сайт и мой офис, у себя в офисе я блокирую все исходящие коннекты кроме идущих на удалённый 80-й порт (белый список портов, запрещено всё, что не разрешено явно). Что увидят мои юзеры на вашем сайте?

[Horse]

Теперь понял. Да, печально.

Answer 6

[Wott]

Если не поднимать кэш то все уже описали. Но я особо не вижу смысла в этом — лучше уж перейти на workers на apache.

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

Как отметили nginx хорошо обрабатывает статику, но если ее много, то эффективнее
— обьединить скрипты и стили в общий файл
— вынести графику на другой домен
— оптимизировать мелочь в спрайты
хотя конечно это все диагнозы по телефону.

Comments

[netherneon]

Нет, возможности изменять код сайтов нет. Большая часть сайтов джумлы друпалы с большой посещаемостью на которых что то изменяется раз в день примерно. Апач сейчас уедает ну очень много памяти. Будет ли ощутимый эффект от установки фронт эндом nginx'a? Может еще дополнительно prefork на worker заменить в апаче? Но это нужно пересобирать, оправдано ли это?

[pentarh]

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

[Wott]

память для апача с prefork уменьшиться пропорционально тому сколько запросов отберете у него — много статики — будет хороший эффект.
Дополнительно менять на worker не надо — если ставите nginx фронт-ендом, все полезное что можно получить от тредов вы получите от nginx.

Хотя оптимизация — такая вот незагадочная штука — надо пробовать и смотреть цифры. Все разговоры только приблизительно ограничивают рамки вариантов.

[Владимир Чернышев]

> — вынести графику на другой домен

Всегда интересовал такой совет, что он даст? Я понимаю вынести их на другой хост, но на другой домен — замена server { server_name example.com; location /image/ {...}; location / {...}; } на server { server_name image.example.com; location / {...} } server { server_name example.com; location / {...} } сулит какой-то дополнительный профит?

[Wott]

Профит на клиентской стороне. На каждый домен ограниченное количество соединений и отделение графики ускоряет загрузку страницы. Серверу от этого в общем-то пофиг, даже местами хуже ибо увеличивается скученность запросов и количество одновременных запросов, но последнее nginx-у пофиг, апачу с prefork — нет.

Answer 7

[pentarh]

В общем случае проблем быть не должно если

1. Nginx будет проксировать динамические запросы апачу
2. Если у апача будет корректно настроен mod_rpaf

Про все про это можно почитать тут Практическое применение nginx на отдаче статики