Comment puis-je empêcher un délai d'expiration de la passerelle avec FastCGI sur Nginx

203

J'utilise Django, FastCGI et Nginx. Je crée une sorte d'api où quelqu'un peut envoyer des données via XML que je traiterai puis retournerai des codes d'état pour chaque nœud qui a été envoyé.

Le problème est que Nginx lancera un délai d'expiration de la passerelle 504 si je prends trop de temps pour traiter le XML - je pense que plus de 60 secondes.

Je voudrais donc configurer Nginx de sorte que si des demandes correspondant à l'emplacement / api ne dépassent pas 120 secondes. Quel cadre accomplira cela.

Ce que j'ai jusqu'à présent, c'est:

    # Handles all api calls
    location ^~ /api/ {
        proxy_read_timeout 120;
        proxy_connect_timeout 120;
        fastcgi_pass 127.0.0.1:8080;
    }

Edit: ce que j'ai ne fonctionne pas :)

configuration nginx fastcgi

— sheats
source

7

Vous pouvez définir des valeurs de temporisation sur "2m" au lieu de "120".

— Cenk Alti

1

Il semble mauvais que les données ne soient pas diffusées ... c'est-à-dire qu'un serveur qui commence à répondre en 60 secondes ou plus semble inacceptable.

— Adam Gent

245

Les délais d'attente de proxy sont bien, pour les proxies, pas pour FastCGI ...

Les directives qui affectent les délais d'attente FastCGI sont client_header_timeout, client_body_timeoutet send_timeout.

Edit : Compte tenu de ce qui se trouve sur le wiki nginx, la directive send_timeout est responsable de la définition du délai d'expiration général de la réponse (ce qui était un peu trompeur). Pour FastCGI, il y a fastcgi_read_timeoutce qui affecte le délai de réponse du processus fastcgi .

HTH.

— zgoda
source

8

Pour toute personne utilisant uwsgi et ayant cette erreur, uwsgi_read_timeout 600; résolu mon problème.

— Homer6

2

Ma question ici serait (en tant qu'administrateur de serveur amateur) où dois-je changer cela? Fichier httpd.conf?

— jeffkee

2

Si cela peut aider, le mien était sur / etc / nginx / sur le système DV de Media Temple.

— jeffkee

Abdo donne un bon moyen de déboguer. Si vous rencontrez toujours des problèmes, vous devrez peut-être augmenter la taille maximale des messages client dans nginx.conf (client_max_body_size ** M;)

— Sam Grondahl

2

Augmenter le délai d'expiration n'est pas une bonne solution.

— JazzCat

24

Pour ceux qui utilisent nginx avec licorne et rails, le délai d'attente est probablement dans votre unicorn.rb fichier

mettre un grand timeout dans unicorn.rb

timeout 500

si vous rencontrez toujours des problèmes, essayez d'avoir fail_timeout = 0 dans votre amont dans nginx et voyez si cela résout votre problème. C'est à des fins de débogage et peut être dangereux dans un environnement de production.

upstream foo_server {
        server 127.0.0.1:3000 fail_timeout=0;
}

— Abdo
source

3

Je pense que les gens l'ont rejeté parce qu'il s'agit de Django, mais votre réponse a résolu mon problème de délai d'attente de passerelle avec Rails + Unicorn :)

— ZiggyTheHamster

4

Dans la httpsection nginx (/etc/nginx/nginx.conf) ajoutez ou modifiez:

keepalive_timeout 300s

Dans la serversection nginx (/etc/nginx/sites-available/your-config-file.com) ajoutez ces lignes:

client_max_body_size 50M;
fastcgi_buffers 8 1600k;
fastcgi_buffer_size 3200k;
fastcgi_connect_timeout 300s;
fastcgi_send_timeout 300s;
fastcgi_read_timeout 300s;

Dans phple dossier 127.0.0.1:9000 (/etc/php/7.X/fpm/pool.d/www.conf), modifiez:

request_terminate_timeout = 300

J'espère vous aider.

— Jose Carlos Ramos Carmenates
source

Est-ce que quelque chose de "mauvais" arriverait si je change le temps à 10000 secondes?

— utdev

Il ne se passe rien de mal, mais votre service attend plus de temps. Vous pouvez changer sa valeur comme vous le souhaitez.

— Jose Carlos Ramos Carmenates

1

Si vous utilisez la licorne.

Regardez topsur votre serveur. Unicorn utilise probablement 100% du CPU en ce moment. Il existe plusieurs raisons à ce problème.

Vous devriez vérifier vos requêtes HTTP, certaines peuvent être très difficiles.
Vérifiez la version de la licorne. Il se peut que vous l'ayez mis à jour récemment et que quelque chose soit cassé.

— Pavel Kalashnikov
source

0

Dans le serveur proxy défini comme ça

location / {

                proxy_pass http://ip:80;                

                proxy_connect_timeout   90;
                proxy_send_timeout      90;
                proxy_read_timeout      90;

            }

Dans le serveur php défini comme ça

server {
        client_body_timeout 120;
        location = /index.php {

                #include fastcgi.conf; //example
                #fastcgi_pass unix:/run/php/php7.3-fpm.sock;//example veriosn

                fastcgi_read_timeout 120s;
       }
}

— Kamil Dąbrowski
source