shoorick | Entries tagged with nginx

Как я только не запускал перловые скрипты на веб-серверах — и как CGI, и как mod_perl (на обоих апачах), и как FastCGI через nginx.

А какой способ принято сейчас использовать?

Мы завели отдельную железяку под перловый хостинг, чтоб выселить туда всё перловое: несколько сайтов на Mojolicious, Catalyst и Movable Type плюс древний самописный кошмар, который давно переписать на чём-нибудь современном.

Хочется сделать это хорошо и правильно. Как быть? Что читать?

Current Mood: perlbrew install perl-5.16.3
Current Music: дождь стучит по карнизу

Перенёс накопленное в траке со своей машины в редмайн на боевом сервере. Переношу subversion в том же направлении и задумался об оптимизации серверной части.

Svnserve, конечно, быстрый, но вводить пароли при доступе через svn+ssh:// задолбало, да и по непонятной причине он игнорирует ключ -r, а длинные URL типа svn+ssh://name.of.server/many/many/dirs/before/repo/project/trunk как-то плохо выглядят.

Раскочегаривать апач только лишь для Subversion как-то расточительно. Хотя да, такой вариант будет работать и он же и рекомендован в книге для серьёзных случаев (в том числе и для таких, когда захочется использовать какой-нибудь необычный метод авторизации).

Nginx не все методы поддерживает и, следовательно, на роль обработчика запросов к svn как-то не очень годится — разве что воткнуть его прокси-сервером (а смысл?)

Думал поставить к редмайну пару модулей — redmine_webdav и нужный для него redmine_http_auth (как обычно, пришлось дорабатывать напильником, добавляя перевод на русский). Поставил, почитал документацию внимательнее: им тоже нужен апач (фактически, они позволяют, вроде бы, авторизоваться через редмайновую базу). Если никакого апача не ставить, а запустив сервер webrick, обращаться к нему — он не пускает, но при этом спрашивает пароль.

Продолжаю гуглить...

upd/00:45: Надоело гуглить, воткнул апач, спрятал за нгинксом (just for lulz) — работает. Надо снести ненужные модули и лечь спать.

Предыдущие замеры производительности каталистовых серверов были не вполне чисты: на некоторых серверах использовалась тестовая версия БД, на некоторых — боевая. Хоть обе базы живут на одной машине и управляются одни SQL-сервером, их содержимое не совпадает. Понятно, что различие в содержимом может оказывать влияние на скорость — надо было сразу взять напильник в руки и настроить все серверы на использование одной и той же версии базы.

Сегодня протестировал с одинаковой базой — выяснил, что скорости апача и nginx + Catalyst::Engine::HTTP::Prefork совпадают. Более того, апач иногда проигрывает несколько процентов. Получается, что выбор не той базы давал апачу незаслуженное преимущество, достигавшее нескольких десятков процентов.

В итоге данные заметно поменялись: ( И теперь график выглядит так: )

Попробовал позавчера найти экспериментальным путём лучшее (с точки зрения производительности) количество дочерних процессов, с которыми следует запускать nginx + Catalyst::Engine::HTTP::Prefork и Apache + mod_perl.

Апач настраивал изменением параметра MaxClients в httpd.conf.

Связку нгинкса с каталистовым сервером — чуть сложнее: нгинкс не трогал, а менял параметры каталистового сервера: методу AppName->run можно, помимо прочих параметров, передать max_servers, задающий максимально допустимое количество создаваемых сервером дочерних процессов.

Картина получилась достаточно странная:

Зависимость производительности от числа запущенных процессов

Зависимость производительности от числа запущенных процессов

Хотя результат по-прежнему зависит непонятно от чего: например, сегодня оба варианта показали бóльшую производительность, но с прежним соотношением: 9 к 12.

Либо можно попытаться ускорить само каталистовое приложение (Как? Менять шаблонизатор? Оптимизировать SQL-запросы? Апгрейдить железо? Выбрасывать бэкенд на отдельную машину?) — и не забивать себе голову подобными соревнованиями.

upd/21.01.2010: Более точное тестирование показало равную производительность апача и нгинкса.

По результатам гуглений и бубнений настроил nginx и каталист для совместной работы. В нгинксовом конфигурационном файле в моём случае надо указать, что фронтенд должен передать бэкенду не только своё имя, но и порт:

proxy_set_header   Host             $host;
proxy_set_header   X-Real-IP        $remote_addr;
proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
proxy_set_header   X-Forwarded-Host $http_host;
proxy_set_header   X-Forwarded-Port $http_port;

Это связано с тем, что оба работают на одной машине на разных портах. А каталистовому приложению надо сказать, что оно может быть спрятано от внешнего мира за прокси-сервером. Существуют разные методы, простейший из них — добавить в конфигурацию параметр using_frontend_proxy, равный единице. Чтобы не засорять модули, добавит его в конфиг.yml — это проще всего и вполне работоспособно.

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

Теперь осталось убедиться в корректной работе получившейся связки, проверить способность нгинкса к старту при загрузке системы — и можно будет запускать весь этот комбайн в ~~космос~~ боевую эксплуатацию.

Тестирование производительности по-разному запущенного каталистового приложения показывает неожиданные результаты: апач с мод_перлом с точки зрения производительности оказались более предпочтительными, чем другие варианты: и встроенный сервер (как в конфигурации по умолчанию, так и с CATALYST_ENGINE='HTTP::Prefork'), и nginx+FastCGI работают заметно медленнее, чем апач.

Из всех испробованных вариантов помимо чистого апача годится ещё nginx+Apache — статичные файлы можно раздавать nginx'ом, а динамику — апачем. Хотя сам апач прекрасно справляется и с раздачей статики, он жрёт гораздо больше памяти, чем nginx. С учётом того, что аппетит апача в отношении памяти можно ограничить директивами MaxClients (апач работал и с пятью дочерними процессами — скорость была не хуже скорости с пятьюдесятью процессами) и MaxRequestsPerChild (время жизни дочернего процесса (в принятых запросах), по умолчанию дочерние процессы живут бесконечно, что в данном случае не годится) — видимо такую систему и придётся сооружать (после того, как разберусь с uri_for).

( График спрятан )

Удалось запустить подопытный сайт через nginx+FastCGI. Предварительно пришлось поставить p5-FastCGI-ProcManager, который почему-то не был автоматически поставлен при установке каталиста и обновить libtool, без которого FastCGI::ProcManager не желал ставиться.

Наблюдается интересная картина: производительность, судя по результатам работы ab, в 2–2,5 раза хуже, чем при использовании Apache+mod_perl (но во столько же лучше, чем у каталистового тестового сервера), однако расход памяти заметно ниже: апач на каждый процесс сразу отъедал около 60 метров памяти, процессы размножались и раздувались (до 200 метров на процесс — легко!), потребляя в сумме несколько гигабайт (стремясь сожрать всю доступную память: и физическую, и виртуальную); при использовании FastCGI всё не так: запускается всего 2 процесса со сходными аппетитами на память, один из них ничего не делает, зато другой делает, видимо, всё остальное:

$ topPID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 72718 as 1 125 0 57400K 49068K RUN 1 0:55 74.72% perl 72715 as 1 8 0 56896K 44720K wait 0 0:03 0.00% perl

Статичные файлы, как можно догадаться, раздаются непосредственно nginx'ом. Лёгкие файлы (например, иконка весом менее килобайта) выдаются раза в 2 быстрее, чем апачем, тяжёлые (например, prototype.js — больше 100 кБ) — примерно с одинаковой скоростью.

Попробовал между клиентом и каталистом воткнуть nginx.

Ну воткнул, ну запустил (настроив выдачу статики nginx'ом, а остального, как и раньше — апачем) — а пользы не видно: как апачные процессы жрали процессор — так и жрут, как mod_perl отъедал всё больше и больше памяти — так и отъедает.

Скорость выдачи статики у обоих серверов практически совпадает, а на выдаче динамического контента апач даже чуть-чуть шустрее связки nginx+apache (что предсказуемо).

В чём смысл-то? Разве что вынести backend на другую железяку (или завести несколько бэкендов на разных машинах) — может быть, что-то улучшится. Или попробовать FastCGI в надежде на уменьшение потребления памяти? Непонятно.

Толкового мануала к nginx'у нет (во всяком случае, на сайте разработчика). Ни на русском, ни на английском — лишь какие-то обрывки да разрозненные статьи, раскиданные по интернетам. Вот их и придётся изучать...