Puncte:0

Obținerea erorilor de timeout cu aplicația nginx+gunicorn pe serviciile aplicației Azure

drapel id

Băieți, am nevoie de ajutor cu configurația mea NGINX. În acest moment, aplicația Django este găzduită la serviciile Azure App și mergi direct la Gunicorn funcționează bine, dar când trec prin NGINX încep să primesc erori, ca aceasta:

Am încercat să măresc timpul de expirare, dar erorile continuă să apară sporadic pe diferite puncte finale, iar punctele finale funcționează bine când nu folosesc NGINX, ci doar folosesc gunicorn, așa că cred că trebuie să facă ceva cu setul NGINX - sus.


    2022-01-26T10:22:03.479463450Z nginx | 2022/01/26 10:22:03 [info] 29#29: *2245 epoll_wait() a raportat că clientul a închis prematur conexiunea, deci conexiunea în amonte este închisă și ea în timp ce trimiterea cererii către amonte, client: 169.254.130.1, server: xxxxx .com, cerere: „GET /api/v1/office-hours/ HTTP/1.1”, în amonte: „http://127.0.0.1:8000/api/v1/office-hours/”, gazdă: „xxxxx.com ", referitor: "https://xxxx.vercel.app/"
    2022-01-26T10:22:03.514362267Z nginx | 169.254.130.1 - - [26/Jan/2022:10:22:03 +0000] „GET /api/v1/office-hours/ HTTP/1.1” 499 0 „https://xxxx.vercel.app/” „ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, ca Gecko) Chrome/97.0.4692.99 Safari/537.36"
     
    2022-01-26T10:23:03.513182059Z nginx | 2022/01/26 10:23:02 [info] 29#29: *2247 epoll_wait() a raportat că clientul a închis prematur conexiunea, deci conexiunea în amonte este închisă și ea în timp ce trimiterea cererii către amonte, client: 169.254.130.1, server: xxxxx .com, cerere: „GET /api/v1/office-hours/ HTTP/1.1”, în amonte: „http://127.0.0.1:8000/api/v1/office-hours/”, gazdă: „xxxxx.com ", referitor: "https://xxxx.vercel.app/"
    2022-01-26T10:23:03.513238060Z nginx | 169.254.130.1 - - [26/Jan/2022:10:23:02 +0000] „GET /api/v1/office-hours/ HTTP/1.1” 499 0 „https://xxxx.vercel.app/” „ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, ca Gecko) Chrome/97.0.4692.99 Safari/537.36" 

web | [2022-01-25 17:21:07 +0000] [15] [CRITIC] TIMEOUT LUCRĂTOR (pid:32)
2022-01-25T17:21:07.490138324Z web | 2022-01-25 18:21:07,487 [32mINFO [31mglogging [33mIeșire lucrător (pid: 32)] [34mgunicorn.error.info:264[0m
2022-01-25T17:21:07.490220225Z nginx | 2022/01/25 17:21:07 [eroare] 25#25: *930 conexiune în amonte închisă prematur în timpul citirii antetului răspunsului din amonte, client: 169.254.130.1, server: xxxx.com, cerere: „GET /api/v1 /cms/content/ HTTP/1.1”, în amonte: „http://127.0.0.1:8000/api/v1/cms/content/”, gazdă: „xxxx.com”
2022-01-25T17:21:07.490875232Z nginx | 169.254.130.1 - - [25/Jan/2022:17:21:07 +0000] „GET /api/v1/cms/content/ HTTP/1.1” 502 158 „-” „axios/0.18.1”
2022-01-25T17:21:07.490892833Z nginx | 2022/01/25 17:21:07 [informații] 25#25: *930 client 169.254.130.1 conexiune keepalive închisă
2022-01-25T17:21:08.673367528Z web | [2022-01-25 17:21:08 +0000] [15] [AVERTISMENT] Lucrătorul cu pid 32 a fost concediat din cauza semnalului 9
2022-01-25T17:21:08.679932505Z web | [2022-01-25 17:21:08 +0000] [43] [INFO] Lucrător de pornire cu pid: 43

acesta este nginx.conf-ul meu

#user nginx;
lucrător_procese 2; # Setați la numărul de nuclee CPU, 2 nuclee în planul Azure P1v3

error_log /var/log/nginx/error.log depanare;
pid /var/run/nginx.pid;


evenimente {
    conexiuni_muncitor 1024;
}


http {
    includ /etc/nginx/mime.types;
    aplicație de tip_default/octet-stream;

    log_format principal „$remote_addr - $remote_user [$time_local] „$request” '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log /var/log/nginx/access.log principal;

    sendfile activat;
    #tcp_nopush on;

    keepalive_timeout 65;

    #gzip activat;

    includ /etc/nginx/conf.d/*.conf;
}

acesta este implicit.conf

Server {
asculta 80 default_server;

error_log /dev/stdout info;
access_log /dev/stdout;

client_max_body_size 100M;


locație /static {
    rădăcină /var/app/ui/build;
}

locație /site-static {
    rădăcină /var;
}

locație / media {
    rădăcină /var;
}

Locație / {
    rădăcină /var/app/ui/build; # încercați mai întâi directorul de compilare react, dacă fișierul nu există, trimiteți cererile către aplicația django
    try_files $uri $uri/index.html $uri.html @app;
}

locație @app {
    proxy_set_header Gazdă $gazdă;
    proxy_set_header X-Real-IP $adresă_la distanță;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto „https”; # presupune https deja terminat de echilibrul de încărcare din fața noastră

    proxy_pass http://127.0.0.1:8000;
    proxy_read_timeout 300;
    proxy_buffering dezactivat;
}

}

Puncte:1
drapel us

Trebuie să depanați aplicația, de ce durează atât de mult să răspundă.

Există o întârziere de un minut între trimiterea cererii în amonte de către nginx și renunțarea la așteptarea unui răspuns de către nginx.

nginx se poate conecta la aplicația din amonte prin TCP, poate trimite cererea HTTP. Cu toate acestea, aplicația nu trimite răspunsul înainte ca nginx să expire.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.