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

[Михаил Митрофанов]

Попробовал этот вариант, но скрипт запуска не хочет форкаться.
Висит в консоли.
 

-----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.
>
> С уважением, Юрий.
>