Интересуют ответы на следующие вопросы:
1. кто как использует nginx для поддержки Drupal-проектов:
1.1.) nginx как самостоятельный веб-сервер, - замена apache ?;
1.2.) nginx как front-end сервер в связке с apache ?
2. какой из перечисленных выше вариантов на Вашем опыте более эффективен при высоких нагрузках?
3. какие хостеры используют nginx?
3. представляет ли сложность установить nginx самостоятельно, если он не используется хостером "по умолчанию"?
Отчасти наверное эти вопросы можно адресовать и авторам Drupal.ru - в последние пару дней сайт несколько раз падал (правда ненадолго) и видно было что 502-ю ошибку выдает именно nginx.
Заранее спасибо за ответы,
Денис
Комментарии
Использую nginx по пункту 1.2. работает без проблем.
Установить самому можно все, но если у вас нет рутовых прав на сервер, то невозможно, если только на другом порту.
А не сравнивали с п.1.1 - какой вариант шустрее?
использую как 1.1. Как ставил описывал в блоге.
Насчет 502 ошибки - не знаю, ибо не возникала
Спасибо - прочитал ваш пост в блоге - полезно. А можете сообщить какой сайт на такой конфигурации крутится? и что используете - свой сервер или VPS
http://cwer.ru свой сервер
Мы рекомендуем для наших VPS пункт 1.2 (+с отдачей статики напрямую через nginx).
Да,
1. связка nginx + php/fastcgi менее затратна по памяти.
2. да, связка nginx + apache/modphp работает не медленнее, чем первая связка, но более совместима, и имеет меньше проблем при некоторых случаях.
Всё это для случая, когда Вы используете какой-либо PHP-акселератор. Мы используем в основном eAccelerator.
Установка nginx на наших VPS обычно тривиальна. Можно собрать из исходников, а можно банально выполнить yum install nginx.
На drupal.ru сейчас используется nginx 0.6.34, php 5.2.3 + патч php-fpm, xcache 1.2.2. Mysql 5.0 на отдельном хосте. Общая посещаемость сайтов фронтенда - примерно до 30тыс. в сутки. Все ошибки, которые выдаёт drupal.ru - следствие неудачных настроек и экспериментов, к стабильности nginx претензий нет.
У меня были проблемы. nginx при длительной отработке запроса от fcgi-процесса иногда не дожидался ответа, и показывал пустую страницу, вместо gateway timeout.
Закономерности отследить не удалось.
Я поставил на прошлой неделе nginx как front-end для раздачи статических файлов. О результатах почитать можно тут Nginx как front-end.
Спасибо всем за ответы - полезно !
будет ли работать .htaccess
в связке nginx как фронтэнд(отдача статики) и apache как бекэнд(через proxy_pass)?
.htaccess будет работать для отдачи тех каталогов, которые форвардятся Апачу.
Имеет смысл прописать правило location ~ ^\.htaccess$ в nginx для запрета отдачи файлов .htaccess.
а я после установки nginx не могу включить чистые ссылки вариант похоже 1.1 (ставила поддержка хостинга)что нужно сделать чтоб они заработали не подскажете?
Как вариант:
http://brainstorm.name/drupal-and-nginx-rewrites
Подскажите в каком файле нужно прописывать данный код.
Akzhan, спасибо.
Леха Тутубалин - а автору русского Апача и одному из ведущих программистов Рамблера можно верить - рекомендует в общем случае ngnix для снятия нагрузки с apache и сам apache.
Про чистый ngnix говорит - что это для очень специфических случаев и очень больших нагрузок, крайне сложно в отладке.
судя по коду:
1. location / {
2. root /var/www/brainstorm/htdocs;
3. index index.php index.html index.htm;
4. if (!-e $request_filename ) {
5. rewrite ^(.*)$ /index.php?q=$1;
6. }
7. }
в файле который отвечает за настройку хостов nginx (в случае общего хостинга хостер может и не внести его в конф файл)
nginx предназначен для БЫСТРОЙ ОТДАЧИ СТАТИКИ. Он является БЛОКИРУЮЩИМ сервером. Если пересадить на него Drupal напрямую - он будет неплохо отрабатывать очень небольшое число запросов одновременно, но при росте посещаемости начиная с определенного уровня будет просто ОБЛАМЫВАТЬ очередного посетителя сайта.
Динамика должна перенаправляться на другой сервер, который как раз хорошо умеет работать с динамикой. Один из лучших - Apache.
Кроме того трудно настраивать rewrite без Apache, средствами только самого nginx. Хотя на сайте автора nginx есть пример конкретно для Drupal.
Замечу, что кроме rewrite для целей Drupal бывает нужен rewrite для imagecache и др.
а) nginx как прокси буферизирующий + Apache - эффект хороший, настраивается элементарно.
Смысл вот в чем - Апач на обработку запроса тратит довольно много ценного ресурса - памяти. Деваться от этого некуда - там же PHP, Drupal.
Но после того как ответ готов - пока ответ доедет до посетителя сайта проходит довольно много времени. А ресурсы Апача, обрабатывающие данный конкретный запрос, будут еще заняты. Освободятся они, когда все данные ответа уедут.
nginx берет это на себя. Он получает от Апача ВЕСЬ ответ, складывает его в буфере. Апач, отдав ответ, освобождает ресурсы, связанные с этим запросом. И тут же готов предоставлять эти свежеосвобожденные ресурсы - для обработки следующего запроса.
То, что nginx забрал себе в буфер от неторопливо отдает посетителю сайта. Так как тот ответ, что лежит у nginx в буфере - это по сути примитивный, никак не обрабатываемый файл, то занимает он куда как меньше ресурсов компьютера, нежели куда как более сложные структуры Апача и PHP.
б) Другой вариант - также настраивается просто - статика перекидывается через nginx. Статику он отдает очень шустро, не нагружая сервер.
Причем nginx умеет изменять свое поведение в зависимости от наличия файла.
Например, можно сказать ему, что все файлы по адресу /drupal/sites/mysitename.ru/files/images/* передавать пользователю безо всякого Апача и PHP, а если в указанном месте файла такого нет, то передавать запрос на обработку Апачу, PHP и Drupal.
в) Третий вариант - кэширующий прокси. nginx смотрит заголовки всего что отдается с Апача. И если заголовок ответа разрешает кэширование, то кладет этот ответ в кэш. В дальнейшем, отдает сразу их кэша, не терзая по напрасну ни Apacha, ни соответственно PHP, Drupal, MySQL.
Данный механизм куда как быстрее встроенного кэша Drupal и меньше нагружает сервер.
Нету такого понятия.
Есть понятия - высокая посещаемость анонимусов (элементарно кэшируется), высокая посещаемость зарегистрированных пользователей (не так просто кэшируется), много качают больших файлов, интенсивно используют поиск и пр. и пр. и пр.
Разные случаи оптимизируются - по разному.
На сегодня - наверное большинство.
nginx хорошая штука.
Например у меня хостинг с панелью ISPmanager.
Там все делается парой нажатий на мышку.
Потом допиливаю конфигурационный файл nginx вручную (что вообще говоря необязательно, если нужен только буферизирующий прокси) - вот это несколько муторно.
nginx как-то по особенному должен конфижиться для мультисайтинга?
А скажите мне, зачем вы используете nginx вообще? Для чего? Экономии памяти? Почему не использовать другой MPM Apache?
nginx, в моем случае, существенно разгружает систему. сайт с высокой посещаемостью. апач прожорлив по сравнению с nginx
Ошибочное мнение, жутко ошибочное.
Переключите Apache в mpm-worker и php в режим cgi - поймете. mpm-prefork для мощных систем предназначен, и на них он работает значительно быстрее Nginx. Все должно выполнять свои задачи. Nginx вы используете только для отдачи статики, что вообще не корректно в корне. Для отдачи файлов нужно использовать протокол, специально для этого предназначенный.
Простите, но что вы имеете ввиду?
Если вопрос нубский - обругайте меня, но, будьте добры, ответьте.
Это жутко ошибочное мнение проверено на практике. И в подтверждение моих слов, смотрите обучающее видео Lullabot "Drupal Performance & Scalability", там правда тестируется varnish... но в данном случае хрен редьки не слаще
Вы меня вообще не читали видимо. Дальше дискуссию считаю бесполезной.
специальный протокол, но не через Nginx - автор, видимо, имел ввиду ftp или bittorrent...ага)
ну тогда всё встает на свои места )
Откопали замшелую тему...
Raistlin'а искать на Серче.
По теме: долго пытался работать с mpm-worker во всех качествах сразу, потом надоело, и поставил фронт-эндом Nginx. В бэк-энде пока тот же воркер, особо не крутил. Сервер вздохнул с облегчением.
по поводу настройки вот небольшая инструкция по настройке Nginx фронтендом к апач для отдачи статики.