Puncte:1

uWSGI anulează răspunsurile, pierde conexiunea la nginx

drapel gb

Rulez o mică aplicație web scrisă în Python, care rulează în uWSGI și este servită prin nginx. Există o componentă care generează fișiere ZIP pentru descărcare, care ocazional poate fi destul de mare (câțiva GB). Se întâmplă adesea ca conexiunea dintre nginx și uWSGI să fie întreruptă și cererea să fie anulată; nginx ignoră răspunsul trunchiat în timp ce browserul trece într-un timeout, deoarece menține conexiunea deschisă, așteptând mai multe date de răspuns. Aplicația generează un antet Content-Length adecvat.

Din jurnalul uWSGI:

uwsgi_response_write_body_do(): conductă spartă [core/writer.c line 429] în timpul GET [...]
OSError: eroare de scriere
SIGPIPE: scriere la o conductă/priză/fd închisă (probabil clientul deconectat) la cerere [...] !!!

Am setat deja socket-timeout, socket-send-timeout și socket-write-timeout la 180 în configurația uWSGI, fără niciun rezultat. Conf. nginx include uwsgi_read_timeout 180s; și uwsgi_buffering off;

Efectul este în cea mai mare parte reproductibil, prin aceea că se întâmplă de cele mai multe ori, în special cu răspunsuri mari, dar niciodată la același offset. Repetarea cererii din nou și din nou poate duce în cele din urmă la finalizare.

Michael Hampton avatar
drapel cz
Aceasta pare mai degrabă o problemă de design a aplicației. Solicitările web chiar nu sunt destinate să stea acolo câteva minute în așteptarea unui răspuns. Ar trebui mai degrabă să începeți o lucrare de fundal pentru a crea fișierul ZIP și apoi să oferiți utilizatorului o adresă URL de unde să-i verifice starea sau să ridice fișierul când este complet.
Felix avatar
drapel gb
@MichaelHampton Fișierul este generat din mers. Întârzierea răspunsului este de obicei mai mică de 10 secunde, dar livrarea corpului de răspuns necesită timp. Conexiunea este întreruptă în timp ce răspunsul este deja trimis către client. Agentul utilizator raportează un progres de descărcare uneori 20%, alteori 80%, variind foarte mult, apoi datele nu mai curg și la un moment dat, agentul utilizator raportează un timeout în timpul descărcării.
Michael Hampton avatar
drapel cz
Hmm. Ar trebui să verificați jurnalul de erori nginx.
Felix avatar
drapel gb
Nimic în jurnalul de erori nginx; jurnalul de acces raportează doar cererile cu lungimea trunchiată, ignorând faptul că Content-Length sugerează că conexiunea a fost întreruptă prematur.
Michael Hampton avatar
drapel cz
OK, deci iată o întrebare interesantă. Cum poți ști lungimea fișierului comprimat înainte de a-l comprima?
Felix avatar
drapel gb
Nu comprim fișierele, deoarece de obicei sunt deja comprimate (în mare parte fișiere JPEG), așa că DEFLATE nu va câștiga oricum mult spațiu. Fișierele sunt stocate fără compresie. Primesc o listă de fișiere de trimis și, din dimensiunile acestora, calculez cât de mare va fi exact fișierul zip. Acesta este raportat ca Lungimea conținutului, apoi fișierul ZIP este generat în timp ce este trimis către client. Am testat asta mult, iar calculul lungimii nu este problema.
Puncte:0
drapel gb

Sa dovedit că nici aplicația mea, nici nginx nu a fost problema, ci un filtru de pachete defect în fața ambelor.

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.