ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: nginx (Windows XP) + php-cgi.exe - одно временно обрабатывает т олько один запрос - остал ьные ждут


  • To: nginx-ru@xxxxxxxxx
  • Subject: Re: nginx (Windows XP) + php-cgi.exe - одно временно обрабатывает т олько один запрос - остал ьные ждут
  • From: Sergey Shepelev <temotor@xxxxxxxxx>
  • Date: Wed, 2 Jun 2010 11:41:44 +0400
  • Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=rgF1gtB6o43Ldiuikt39bwoylWN/LB3K5pVv9RZdLNk=; b=ZeVZj4cL0rn8Yff9YAP1Z7+FTH0OoeJuR8815tEwJYxwsFbNbauSyXPkks2KJTU53b zrmBKEa6Qj0UqDy1X4P/bvaRpGJs0Y0WUU4nS+4AxbDgeQLIH9poiZH1b4a95M7+dpQg +iG3PPPcq+T9o5sa40Xdo03GeyD+CBIyTnINQ=
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=YLEof95/YVbQ7UXvbYJ83E9+YQDvctRXNaxugzFoKKvVESvKLuqKj4N1LUgsvilLJi 3Ggj76woAYeLmqRjP9VQkYEshGEdKP+jWJNo1dEV+dFaEqy+LycpWubxg+4XJoJ+dFO9 O0QzmmY8AVbuQThAUlVEJbhLzVWQr5lMlW2oY=
  • In-reply-to: <89684f10947971b8903238a9201db225.NginxMailingListRussian@xxxxxxxxxxxxxxx>
  • References: <9134bf8edb187f89eeccc31c74c61e1c.NginxMailingListRussian@xxxxxxxxxxxxxxx> <89684f10947971b8903238a9201db225.NginxMailingListRussian@xxxxxxxxxxxxxxx>

2010/6/1 iWarior <nginx-forum@xxxxxxxx>:
> [i]По поводу количества процессов: скорее хватит 20-30 (и не забываем 
> кешировать ответы бекендов), хотя, конечно, это сильно зависит от
> нагрузки. На linux/freebsd значительная часть памяти у них всех будет общая. 
> Что ещё вас смущает в количестве? На windows да, это мало пригодно. Там нужно 
> использовать потоки, и опять же, память будет общая.[/i]
>
> Это всё замечательно, НО: на linux/freebsd nginx конфигурируется точно также 
> как и на windows - fastcgi_pass ссылается или на [u]один[/u] хост:порт или на 
> [u]один[/u] сокет и этот один fastcgi_pass обслуживает все запросы. И все эти 
> запросы не ждут по одному пока их рассчитают - всё работает параллельно.
>
> В Windows же c php-cgi у меня задачи эти в очередь выстраиваются. Вопрос: 
> Кто-нибудь на Windows такое поднимал, чтобы nginx+php работали нормально на 
> низкой нагрузке? Я что-то не так делаю, или это баг в php-cgi?

Потому что на не-windows, php-cgi с запускает (столько, сколько
записано в переменной окружения PHP_FCGI_CHILDREN) детей, которые
обрабатывают запросы. На windows php-cgi эту переменную игнорирует и
работает в однопоточном режиме.

Да, я вам уже говорил, что, например, я поднимал. И говорил как: нужно
запустить несколько php-cgi. Отдельно. И настроить upstream из
нескольких портов.

> [i]Про upstream всё правильно, да. Таймауты тут не причём, просто по
> очереди перебираются бекенды, да. Есть модуль fair upstream, который
> более хитро выбирает бекенды, чтоб они равномерно были загружены.[/i]
>
> Косяк в том, что upstream перебирает бекенды случайно с учётом весов и 
> прочего, плюс прибивает мёртвые бекенды. Но занятый php-cgi не мёртвый, 
> поэтому он не исключается даже по нулевому таймауту, и если при переборе не 
> повезёт, то ждать ответа придётся ровно столько же, сколько и без upstream. 
> Поэтому такое решение не подходит и смысла плодить php-cgi нету...
>

"прибивает мёртвые бекенды" ? фантазия. Было бы здорово, но увы, нет.
nginx не управляет бекендами.

Начиная с "занятый php-cgi не мёртвый, поэтому он не исключается даже
по нулевому таймауту" тоже фантазия и дальнейшие выводы (долго ждать
ответа, решение не подходит), на ней основанные, неверны.

У вас была проблема с настройкой nginx + несколько отдельных php-cgi
бекендов? Так надо было именно с этой проблемой и обращаться, чтобы
вам посоветовали как её решить. А скоропостижные выводы, типа "так
ничего не выйдет", вашу задачу решить не поможет.

fastcgi_next_upstream error timeout; # это значение по-умолчанию,
проверьте, что вы его не меняли

fastcgi_connect_timeout 1;
и nginx будет пробовать следующий бекенд, следующий и так пока не
найдёт свободный.
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://nginx.org/mailman/listinfo/nginx-ru


 




Copyright © Lexa Software, 1996-2009.