Hello,
nginx-0.5.35.
Пользую FCGI::ProcManager. Обнаружил, что CGI.pm работает неправильно, привязал CGI::Fast.
Переменные из GET берёт хорошо, а из POST --- нет.
Порылся в исходниках FCGI, и понял, что POST обрабатывается в CGI.pm.
Собственно проблема с nginx в том, что я ему пишу в конфиге
===
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
===
а переменные в FCGI::ProcManager попадают в %ENV:
===
HTTP_CONTENT_TYPE
HTTP_CONTENT_LENGTH
===
остальные прописанные в конфиге --- идут как есть. И действительно, вот я вставляю в мой FCGI::Spawn:
===
map { $ENV{ $_ } = $ENV{ "HTTP_$_" } } qw/CONTENT_LENGTH CONTENT_TYPE/
if $ENV{ 'REQUEST_METHOD' } eq 'POST';
===
перед "new CGI::Fast" --- и переменные им берутся как надо.
Вопрос в чём: я всё оставляю как сейчас, или это бага nginx? а то мы спецификаций да сишных исходников не читатели, только почитатели-причитатели :)
73! Peter
--
http://vereshagin.org
Hi, all!
Есть проблемы с использованием weight в upstream в целях распределения
нагрузки.
Если вес выставлен одинаковый, то нагрузка распределяется равномерно.
Пример:
upstream test_backend {
server localhost:59040 weight=10000;
server other_server:59040 weight=10000;
}
Если же выставить разный вес, то нагрузка распределяется неравномерно по
времени, каждые десять минут меняется сервер и все. Сужу об этом по графикам
загрузки серверов. 10 минут все запросы идут на один сервер, затем 10 мин. на
другой.
Пример:
upstream test_backend {
server localhost:59040 weight=10000;
server other_server:59040 weight=5000;
}
location / {
expires epoch;
fastcgi_pass test_backend;
fastcgi_upstream_max_fails 0;
fastcgi_next_upstream error timeout invalid_header http_500;
include fastcgi_param.conf;
}
Но обнаружил, что если цель треть нагрузки отправлять на другой сервер, то
такое помогает:
upstream test_backend {
server localhost:59040 weight=10000;
server localhost:59040 weight=10000;
server other_server:59040 weight=10000;
}
# nginx -v
nginx version: nginx/0.3.60
# uname -a
Linux tapo.net 2.6.8-2-386 #1 Tue Aug 16 12:46:35 UTC 2005 i686 GNU/Linux
К примеру, есть есть PHP скрипт такого содержания:
<?php
for ($i = 0; $i < 30; $i++)
{
echo 'xxxxxxxxxxxxxxxx<br>';
ob_flush();
flush();
sleep(1);
};
?>
Он досылает на клиент новые данные в течении 30 сек с интервалом в 1 сек.
Когда PHP работает как mod_apache, то именно так и происходит. Но в связке
nginx+FastCGI (менеджером FastCGI служит php-fpm) получается так: 30
секунд ни какого ответа, а потом бааах и уже готова страница.
Вот не знаю в какую сторону копать.
Здравствуйте, 1-2 раза в день процесс nginx подвисает в состоянии ufs.
И никаким способом не убивается.
PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND
3587 www 1 -4 0 15224K 2408K ufs 0:25 0.00% nginx
3507 www 1 -4 0 15036K 2284K ufs 0:24 0.00% nginx
3463 www 1 -4 0 15132K 2344K ufs 0:22 0.00% nginx
$uname -a
FreeBSD 77.120.96.219 6.3-RELEASE FreeBSD 6.3-RELEASE #0: Wed Jan 16
04:18:52 UTC 2008
root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386
$./nginx -v
nginx version: nginx/0.7.5
Есть решение?
Добрый вечер!
Есть vBulletin форум, apache-бекенд, nginx-фронтэнд. Юзеры жалуются,
что при нажатии на кнопку "выход" получают 502.
Посмотрел в еррор_лог - там такая запись:
2008/05/16 22:32:31 [error] 29222#0: *39718 upstream sent too big
header while reading response header from upstream, client:
икс.икс.икс.икс, server: www.секрет.com, request: "GET
/forum/login.php?do=logout&logouthash=431a7eac932d78d631c63ce42b23205b
HTTP/1.1", upstream:
"http://127.0.0.1:8000/forum/login.php?do=logout&logouthash=431a7eac932d78d6…",
host: "www.секрет.com", referrer: "http://www.pofig.com/forum/"
Посмотрел документацию, директивы, задающей максимальный размер
принимаемого хидера - нет.
Что делать?
Заранее спасибо.
--
С уважением, Борис Долгов.
icq 77556665
e-mail boris(a)dolgov.name
Здравствуйте!
После переезда я рад вернуться к
OSS-проектам. На этот раз секьюрити релиз:
Версия 2.0.7 (от 18 октября 2008):
* Изменение: ограничение размеров
файлов и тела результативного запроса с
помощью директив upload_max_file_size и
upload_max_output_body_len
* Добавление: директива upload_pass_args
позволяет передавать аргументы
исходного запроса бакэнду. Спасибо Todd
Fisher.
Максимальный размер тела
результативного запроса по-умолчанию
установлен в 100 килобайт. Этого
достаточно, чтобы содержать большинство
форм, и в то же время предотвращает
заполнение памяти большими нефайловыми
полями.
Подробности на странице модуля:
http://www.grid.net.ru/nginx/upload.ru.html
--
Best regards,
Valery Kholodkov
> > я уже писал об этом: виртуальные сервера бывают не только name-based,
> > но и ip-based. то поведение nginx что есть сейчас - позволяет реализовать
> > с помощью одного nginx любые комбинации этих двух типов виртуальных серверов,
> > причем без ввода в конфиг дополнительных директив, вида NameVirtualHost
> > и без ограничения возможностей, как это сейчас можно наблюдать в Apache.
>
> server {
> listen *:80;
> server_name virtual.host;
> }
> server {
> listen 1.2.3.4:80;
> server_name ipbased.host;
> }
>
> Все запросы, пришедшие на 1.2.3.4:80, но не содержащие
> "Host: virtual.host" идут на ipbased. Благодаря правильным
> записям в DNS - такие запросы и не будут ходить на 1.2.3.4
> Если же по какой-то причине нужно, чтобы ipbased обрабатывал и
> запросы с "Host: virtual.host" - тогда придется заменить
> "listen *:80;" на прямое перечисление адресов.
А хотя... Здесь вынужден согласиться. Если внешний адрес
динамический, то без * никак не обойтись. Ладно, сдаюсь :)
PS. Хотя я всё-равно предпочёл бы иметь дополнительный параметр
(ipbased: on). Это было бы и наглядней, и позволило бы нгинксу
отслеживать ошибки конфигурирования. - Т.е. если админ по ошибке
указал два сервера, слушающих один и тот же адрес:порт, но хотя
бы для одного из них указано "ipbased: on;" то можно указать ему
на ошибку.
Обнаружил такой баг
server {
listen *:80;
server_name example.org;
}
server {
listen 1.2.3.4:80;
server_name default;
}
запрос на 1.2.3.4 с Host: example.org попадает не в первый vhost а во
второй
nginx 0.6.31
Итак, имею проблему - есть сервер, работающий на Win HTTP Server API (на
котором работает и IIS), при работе с NGINX ответ сервер шлет только в
HTTP/1.1, т.к. запросы тоже должны быть в HTTP/1.1, иначе бы не определялись
хосты. Получил ответ на мое сообщение:
Ищите на бэкенде некорректно работающие скрипты, которые всегда посылают
> ответ
> HTTP/1.1 несмотря на то, что запрос идет HTTP/1.0
>
> --
> Anton Yuzhaninov
>
Возникает несколько вопросов:
1. Зачем использовать устаревшие протоколы, тем более в HTTP 1.0 нельзя
использовать хост, может тогда NGINX не будет их слать (если уж по стандарту
все делать)
2. Неужели сложно посмотреть, в каком формате идет ответ от сервера и
если там есть Transfer-Encoding: chunked, НЕ чанковать повторно?!
--
С Уважением, Андрей Погорельцев!