Puncte:1

UWSGI blochează conexiunile de intrare când toate firele sunt ocupate

drapel cn

Am o aplicație UWSGI simplă pusă în spatele unui LB cu următoarea configurație .ini

[uwsgi]
socket=0.0.0.0:5071
chdir = src/
wsgi-file = uwsgi.py
procese=2
fire=1
protocol=http
plugins=python
exit-on-reload=fals
maestru=adevarat
# Curățarea fișierelor temporare
vid = adevărat    

Când toate 2x1 firele sunt ocupate, aplicația continuă să servească conexiunile de intrare punându-le în coadă, așteptând eliberarea unui fir.

Acesta este cumva un comportament nedorit în cazul meu, deoarece aș dori ca UWSGI să returneze un cod de stare 5xx, care îmi va permite să nu suprasaturam resursele unei singure distribuții.

Cod de testare client

Atașarea codului client de testare pentru aplicația UWSGI

proxy = {
    „http”: „http://localhost:5071”
}

@filetat
def f():
    print('Se trimite cererea')
    răspuns = requests.get('http://dummy.site',proxies=proxy)
    print(str(response.status_code )+ response.text)

pentru i în intervalul (5):
    f()

Test (1)

Adăugând asculta = 2 la .ini și lansarea a 3 solicitări simultan ar imprima doar:

*** coada de ascultare uWSGI a socketului „0.0.0.0:5071” (fd: 3) plină !!! (3/2) ***

în timp ce a treia conexiune pare să fie încă acceptată cumva, pusă în coadă și ulterior executată în loc de a 5xx eroare fiind aruncată.

Test (2)

Adăugând asculta = 0 la .ini și lansarea a 5 solicitări simultan ar executa doar două solicitări simultan. Ieșirea completă a cozii nu se mai afișează. Într-un fel, solicitările sunt încă puse în coadă și executate când firele sunt eliberate.

Cum pot bloca conexiunile de intrare la aplicația UWSGI când toate firele sunt ocupate?

anx avatar
drapel fr
anx
Configurația dvs. are un port și o coadă de ascultare diferită de mesajul înregistrat. Executați două instanțe și verificați o altă instanță decât ați vrut? De asemenea, *aproape* fiecare caz de utilizare funcționează mai bine cu (cel puțin puțin) așteptări de ascultare - când ați terminat, verificați dacă valorile dvs. de performanță se potrivesc într-adevăr cu așteptările dvs.
Constantin avatar
drapel cn
@anx doar o greșeală când am schimbat porturile în timp ce scriam întrebarea. În ceea ce privește întârzierea, la ce opțiune(e) vă referiți în mod special?
anx avatar
drapel fr
anx
Clientul pe care îl utilizați pentru a testa acest lucru poate **reîncercă** *după ce* uwsgi refuză încercarea de conectare o dată? Poate că configurația dvs. a funcționat, dar metoda dvs. de testare nu a funcționat?
Constantin avatar
drapel cn
@anx Nu reîncearcă deloc, folosind simplu `requests.get(url,proxies)` în python
Puncte:0
drapel cz

Aceasta este o cerere cu adevărat bizară, dar dacă chiar doriți să faceți acest lucru, puteți încerca să reduceți coada de ascultare (la zero), adică --ascultă 0. Nu am testat acest lucru și nu știu dacă zero este chiar considerat o valoare validă. Acesta este ceva ce este în mod normal a crescut pe măsură ce un site câștigă trafic, nu scade.

Constantin avatar
drapel cn
Cu `ascultă = 0` tot ceea ce se întâmplă este că ieșirea cozii fiind plină nu mai apare. Se pare totusi ca "pe undeva" atarna pana se elibereaza firele. Am atașat clientul meu de testare la întrebare. Mulțumesc!
Michael Hampton avatar
drapel cz
@Constantin S-ar putea ca acest lucru să nu fie posibil. Nu am găsit pe nimeni altcineva care să încerce să facă asta.
Constantin avatar
drapel cn
Multumesc pentru feedback.Acest lucru este de fapt ciudat - mă întreb de ce nu ar trebui un server web să aibă capacitatea de a fi limitat la cantitatea de conexiuni. Mai ales atunci când aceste aplicații sunt puse în spatele unei întregi infrastructuri menite să funcționeze cu echilibratori de încărcare, grupuri de scalare automată și resurse calculate pre-alocate

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.