Hello!

On Mon, Apr 06, 2020 at 07:17:30AM -0400, gewisser wrote:

> Всем привет. Имеем под windows:
>
> run php-cgi.exe -b 127.0.0.1:9001-c php.ini
> run php-cgi.exe -b 127.0.0.1:9002-c php.ini
> run php-cgi.exe -b 127.0.0.1:9003-c php.ini
> run php-cgi.exe -b 127.0.0.1:9004-c php.ini
> run php-cgi.exe -b 127.0.0.1:9005-c php.ini
>
> upstream backend {
> server 127.0.0.1:9001;
> server 127.0.0.1:9002;
> server 127.0.0.1:9003;
> server 127.0.0.1:9004;
> server 127.0.0.1:9005;
> }
>
> Есть проект в котором скрипт php выполнив определённую работу, должен
> продолжить работу в фоне.
> Раньше с Apache у меня работал вот этот кусок кода:
> https://gist.github.com/bubba-h57/32593b2b970366d24be7
>
> Решил хоть как то заставить это работать с nginx. Для начала попытался
> отключить буферизацию ответов FastCGI:
> header("X-Accel-Buffering: no");
>
> И ответ стал возвращаться браузеру.
> По логике работы web приложения, в браузере к nginx идут последующие
> запросы... и вот тут то возникают для меня непонятки. Следующий запрос как
> правило (но не всегда) остаётся в режиме "pending" и остаётся до того как не
> истечёт "fastcgi_read_timeout" по умолчанию 60 сек.
>
> По какой то причине nginx зная, что один из апстримов находится в режиме
> ожидания ответа, последующий запрос ставит в очередь на этот апстрим и не
> выбирает другой... Чтобы nginx выбрал другой upstream, нужно соединение с
> браузером которое может быть keep-alive разорвать. Чтобы разорвать
> соединение нужно отправить заголовок header("Connection: close"); который
> при любых обстоятельствах не пропускается nginx брвузеру.

То, что "один из апстримов находится в режиме ожидания ответа" - в
общем случае никак не влияет на то, может ли бекенд отвечать на
другие запросы по другим соединениям. В норме - может. Если у
вас не может - нужно принимать специальные меры, чтобы
ограничивать соединения к одному бекенду. В простейшем случае -
можно использовать least_conn балансировку
(http://nginx.org/r/least_conn/ru). В вашем случае, впрочем, это
не поможет, потому что проблема в другом.

Проблема не в том, что nginx "последующий запрос ставит в очередь
на этот апстрим и не выбирает другой", проблема в том, что запрос
к бекенду - не завершён, и соответственно обработка запроса от
клиента - не завершена. Очередной запрос от клиента в том же
соединении по HTTP/1.1 - не будет обрабатываться, пока предыдущий
не завершён.

> Мы можем выставить fastcgi_read_timeout, например в 2 секунды и тогда nginx
> закроет по таймауту соединение с апстримом, скрипт успешно выполнит свою
> долгую работу в фоне, апстрим будет свободен для приёма сообщений и т.д.
> но! Что если нам реально нужно ждать ответ от апстрима более 2,3,4...100
> сек?
>
> Как можно сказать nginx закрыть соединение с fastcgi? А лучше аналогично как
> мы через хедеры говорим nginx не буферизовать вывод (X-Accel-Buffering: no),
> так же сказать закрыть соединение с апстримом.
>
> PS.
> Про FPM и fastcgi_finish_request() знаю.

Чтобы завершить обработку предыдущего запроса - нужно завершить
запрос в рамках протокола FastCGI, именно это делает
fastcgi_finish_request(). Все остальные "решения" - это костыли
той или иной степени опасности и некорректности.

Если fastcgi_finish_request() по какой-то причине не подходит -
то, вероятно, проще всего будет сделать отдельный location для
запросов, в которых предполагается долгая обработка "в фоне", и
выключить там keepalive с помощью директивы keepalive_timeout
(http://nginx.org/r/keepalive_timeout/ru).

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru