Nginx + PHP-FPM = 504?

Question

[Дмитрий Сонько]

Суть вопроса, есть внутренний сервис. Есть формы, с формы отправляется запрос на скрипт на сервере. Скрипт выполняется долго. В итоге через минуту после отправки, энжинкс вылетает с 504й. Ставил все возможные таймауты в его конфиге, выкрутил по максимум время выполнения пхп скриптов. Подскажите пожалуйста, в какую сторону копать, ответ все равно приходит через минуту и именно 504.

Answer 1

[Влад Животнев]

Если php-fpm по tcp, то:
proxy_read_timeout 180;
proxy_send_timeout 180;

Если через сокет, то:
fastcgi_read_timeout 180;
fastcgi_send_timeout 180;

Ещё для обоих случаев.:
client_body_timeout 180;
send_timeout 180;

grep -rni timeout /etc/php5/fpm/ покажите заодно.

Comments

[Дмитрий Сонько]

Я просто огромная балда. Давно не поднимал сие, и указал значения таймаутов через знак равно, а не через пробел =\ Странно, что обранужил это случайно, вызвав сам nginx, а не service nginx. Первый сразу наругал меня за конфиг, а второй молчал как партизан. По сабжу да, необходимо указывать эти две настройки.

Answer 2

[Раиль Хамдеев]

Приведите конфиги php.ini и конфиги nginx.
Также можно посмотреть phpinfo() ибо бывает что конфигов много и использоваться может не совсем тот что нужно. А так вы увидете применились ли ваши настройки или нет.

Answer 3

[alex1234]

а код скрипта? В нём нигде не может определяться максимальное время?

Answer 4

[Алексей Сундуков]

@inkvizitor68sl конечно дал правильное направление. Но хочется добавить еще несколько важных моментов на случай, если окажется, что в конфиге все таймауты прописаны как у него по 180 сек, а скрипт таки отваливает все равно в районе минуты. Соль в следующем.

Если из PHP ни чего не возвращает до конца своей работы, то в действие вступает такая настройка как fastcgi_connect_timeout. proxy_read_timeout тут еще не работает (т.к. по сути соединение не считается установленным). Причем максимальная величина fastcgi_connect_timeout - 75 секунд и это величина захаркожена в самом nginx. Поэтому если скрипт должен работать дольше, то нужно из PHP echo-нуть что нибудь.

Comments

[Борис Сёмов]

Просто echo может не помочь - буферизация.

[Влад Животнев]

Очень уж маловероятно, что приложение за 60 секунд (дефотлное значение) не сможет сказать "ага, я тут, давай заголовки". И "скрипт работает дольше" в данном случае не должно касаться этого таймаута - в fpm скрипт не должен начинать работать до того, как установится соединение (и connect_timeout станет неактуален). Так что в данном случае не время работы скрипты было бы виновато, а загруженность всех тредов php настолько, что за 60 секунд никто из них не смог ответить вебсерверу открытием коннекта.

[Алексей Сундуков]

@kotomyava может. Буферизация на уровне PHP на уровне же PHP элементарно отключается/включается. Проверено, отлично все работает.

Answer 5

[Борис Сёмов]

Есть более правильное решение - выполнять долгие процессы не в контексте веб сервера, разделяя интерфейс постановки задачи и её выполнения.
Например, ставить задачи через веб интерфейс, а выполнять в скрипте запускаемом кроном.

Если надо получать обратную связь, можно периодически записывать процесс выполнения в какое-нибудь хранилище (файл, база, key-value), и отображать его на стороне клиента, делая периодические ajax запросы.