Re: nginx+Django FastCGI, реакция на ответ 302 (редирект)

[Sergey Shepelev]

То что он висит в консоли - очень удобно для отладки.

Я не говорил, что он должен магически демонизироваться (нигде не было
упомянуто PID-файлов).

Демонизацию делайте через start-stop-daemon -b или, гораздо лучше,
запускайте скрипт через daemontools или upstart. Оба варианта
позволяют перезапускать падающие сервисы, чтоб они работали вечно.

2009/5/21 Михаил Митрофанов <m.mitrofanov at elec-co.ru>:
> Попробовал этот вариант, но скрипт запуска не хочет форкаться.
> Висит в консоли.
>
>
> -----Original Message-----
> From: owner-nginx-ru at sysoev.ru [mailto:owner-nginx-ru at sysoev.ru] On Behalf Of Sergey Shepelev
> Sent: Thursday, May 21, 2009 11:21 AM
> To: nginx-ru at sysoev.ru
> Subject: Re: nginx+Django FastCGI, реакция на ответ 302 (редирект)
>
> Очень советую spawning. Это WSGI-HTTP сервер. Не надо заморачиваться с FastCGI. Все прелести proxy_pass, в том числе новое модное кеширование работает.
> У меня работает на живых серверах прекрасно.
>
> #!/bin/bash
>
> : ${HOST=127.0.0.1}
> : ${PORT=8099}
> : ${PROCESSES=$(grep -cs processor /proc/cpuinfo || echo 1)}
> : ${THREADS=16}
> : ${SETTINGS_MODULE=page_builder.settings}
> OPTS="--host=$HOST --port=$PORT --processes=$PROCESSES --threads=$THREADS \
>      --factory=spawning.django_factory.config_factory $SETTINGS_MODULE"
> if [[ "$ACCESS_LOG_PATH" && "$ACCESS_LOG_PATH" != "-" ]]; then
>    OPTS+=" --access-log-file=$ACCESS_LOG_PATH "
> fi
>
> # >/dev/null redirect hides spawning debug messages exec spawn $OPTS > /dev/null
>
> Вот такой нехитрый скрипт запускает N=кол-во ядер процессов, в каждом
> 16 тредов. По процессу на ядро позволяет выжать 100% проца в случае большой нагрузки.
>
> Тот же скрипт в цвете http://paste.pocoo.org/show/118314/
>
> Еще у spawning есть фича, если приложение не блокируется (то есть не лезет в сеть, базу и на диск, а просто рендерит шаблоны из запросов), то есть смысл поставить  THREADS=0  это включает асинхронный движок eventlet. Все запросы будут обрабатываться в одном потоке, асинхронно, как в nginx. Огромные преимущества при большой нагрузке. При маленькой нагрузке (<100 req/s) смысла нет: потоки справятся с запросами, а с сетью nginx-фронтенд.
>
> 2009/5/21 Yuriy Taraday <yorik.sar at gmail.com>:
>> Добрый вечер.
>>
>> Я использую связку nginx+Django. Цель - заставить приложение работать
>> в определённом каталоге сервера без изменений. То есть, чтобы запросы
>> вида http://server/basedir/dir/something приходили в приложение как
>> /dir/something, а возвращаемые редиректы на /otherdir/thing
>> превращались в http://server/basedir/otherdir/thing.
>>
>> При работе через модуль proxy с http-сервером Django, запросы и
>> http-редиректы обрабатываются корректно без особых настроек:
>> location /basedir/ { proxy_pass http://127.0.0.1:8000/; }
>>
>> При работе через модуль fastcgi, чтобы отрезать basedir от пути,
>> приходится пользоваться alias или rewrite (и передавать соотв. строку
>> в параметре REQUEST_URI), но при этом если приложение возвращает
>> ошибку 302 (Temporary moved), то в заголовке Location преобразований
>> пути не делается, и пользователю в приведённом примере прийдёт
>> редирект на http://servеr/otherdir/thing.
>>
>> Хотелось бы узнать, как можно корректно настроить поведение связки
>> через FastCGI.
>>
>> С уважением, Юрий.
>>
>
>