Запустил каталист через FastCGI

[shoorick]

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

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

$ top

  PID 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 кБ) — примерно с одинаковой скоростью.

Comments

Catalyst::Engine::HTTP::Prefork

[imesto-service.livejournal.com]

А пробовали сравнивать с nginx + Catalyst::Engine::HTTP::Prefork?

location /myapp/ { # Or, simply "location /"
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_pass http://localhost:3000/;
}

p.s.
Статику типа css и скриптов еще можно gzip'ить.., чтобы не отдавать 100Кб prototype.js

Re: gzip

[shoorick.livejournal.com]

Кстати, да — правильная мысль. В понедельник попробую загзиповать.

Re: gzip

[shoorick.livejournal.com]

Посмотрел в конфиг — там уже написано gzip on;
Попробовал его закомментировать — скорость (по результатам замеров с помощью ab) не поменялась.
Раскомментировал обратно.

Re: gzip

[imesto-service.livejournal.com]

А там уже есть

gzip_proxied any;
gzip_types application/x-javascript text/javascript text/css;

?

Re: Catalyst::Engine::HTTP::Prefork

[shoorick.livejournal.com]

Сравнил с Catalyst::Engine::HTTP::Prefork — его скорость сравнима со скоростью апача с мод_перлом: кое-где он работает шустрее, кое-где — медленнее. Но памяти ест существенно меньше: во-первых, каждый процесс ест метров по 60, а не по 200, во-вторых, количество процессов можно задать, в-третьих, после снятия нагрузки лишние скрипты тихо дохнут, в-четвёртых, каждый процесс после обработки какого-то числа запросов (если верить документации, по умолчанию после 1000 запросов) перезапускается, что тоже, мне кажется, должно служить предохранителем от прожорливости.

Сейчас тестирую с разным количеством дочерних процессов (от 5 до 50 с шагом 5). Результаты пока какие-то странные, наверное, сказывается отсутствие чистоты эксперимента.

[wisest-owl.livejournal.com]

Сколько процессов было при запуске через mod_perl и сколько при запуске через FastCGI?

Может если сделать количество одинаковым, то и результат будет более похожим, а не в разы?

Re: Сколько

[shoorick.livejournal.com]

До нескольких десятков при использовании mod_perl (удавалось запустить не
более 70 процессов при многопоточном нагрузочном тестировании). И всего 2 —
при работе через FastCGI. Во всяком случае, команда top показывала всего 2
перла, работавших в тот момент.

А насчёт тестирования на равном числе процессов — здравая мысль. Попробую.

Re: Сколько

[shoorick.livejournal.com]

Попробовал. Всё равно апач заметно вырывается вперёд. Сравнимый с апачным результат только у тестового сервера, запущенного через Catalyst::Engine::HTTP::Prefork — все остальные проигрывают.