Metrika pro odpojení spojení z proxy serveru

[petersveter]

Mam proxy server ktory sluzi ako api gateway vlastne. Mam zakladnu logiku na limitovanie requestov a blokovanie(ban) ip adries. Ale rozmyslam ze aku metriku pouzit pre odpajanie spojeni, respektive time out. Mam tym na mysli, ci mam sledovat ramku napriklad, alebo nejak limitovat aktivne spojenia, alebo pocitat priemernu odozvu backendu a ked stupne nad nejaku uroven tak proste nove spojenia nespajat... co je dobra metrika?

[Reklama]

[alex6bbc]

a tvoje api je verejne a bez omezeni?
tak navys vykon hardware.

nebo pokud to mas mit omezene, tak zaved registraci a povoluj jen requesty od registrovanych.

[petersveter]

a tvoje api je verejne a bez omezeni?
tak navys vykon hardware.

nebo pokud to mas mit omezene, tak zaved registraci a povoluj jen requesty od registrovanych.

Kontrolovat pristup je jasne, to tu neriesim. Pytam sa na hardverove metriky. Napada ma, ze co sa backendu tyka, mozno ked dostanem 5xx error, tak na nejaku dobu, minutu, dropnut kazdy druhy request a ulavit tak backend serveru. A s kadym 5xx errorom toto obdobie predlzit proste, cim teda docielim 50% znizenie naporu na backend server.

Co sa samotnej proxy tyka, je mozne nastavit limit na maximalny pocet spojeni, ale zase to je take umele limitovanie kedy backend nemusi mat problem zvladat viac a teda limitovat ludi je kontraproduktivne. Mozno len sledovat ramku a nedovolit nove spojenia kym neklesne pod 90% vyuzitia mi pride ze to ma celkom aj hlavu aj petu.

[alex6bbc]

a nevadi klientovi dropnuti spojeni? nebylo by treba lepsi spojeni prijmout, ale pokud je server zatizeny, tak spojeni nechat cekat a pozdeji zacit zpracovavat. ale to zavisi na povaze aluzby.

[alex6bbc]

a nebo to z proxy loadbalancovat na vice backendovych serveru.

[Reklama]

[RDa]

Kontrolovat pristup je jasne, to tu neriesim. Pytam sa na hardverove metriky. Napada ma, ze co sa backendu tyka, mozno ked dostanem 5xx error, tak na nejaku dobu, minutu, dropnut kazdy druhy request a ulavit tak backend serveru. A s kadym 5xx errorom toto obdobie predlzit proste, cim teda docielim 50% znizenie naporu na backend server.

Jestli chces delat tohle, tak bys musel mit "connection tracking", tj vedet ktere dotazy patri kteremu klientovi resp. ktere session.

Jinak takova modulace requestu zpusobi ze kazdemu pojedou requesty napul a tudiz to kazdemu rozbijes.

Pokud nechces delat connection tracking na proxy uzlu, tak musis mit napsane klienty tak, aby delali retry na api-call, treba s logaritmickym casem (1s, 2s, 4s... treba az po 64s a tam pak delat dotazy uz stejnou dobu - a mit moznost to prezentovat rozumne uzivateli - neco jako tocici se kolecko, proste "busy" ci primo jako "not responding, retrying.." )

[alex6bbc]

client udela request, nejde tak nic. je volny vykon tak dostane token. kdyz neni vykon tak se zpracuji uz jen requesty co ziskaly token.

[petersveter]

client udela request, nejde tak nic. je volny vykon tak dostane token. kdyz neni vykon tak se zpracuji uz jen requesty co ziskaly token.

Ved jasne ale tato cela tema je prave o tom ze co urcuje ci je vykon.

[RDa]

client udela request, nejde tak nic. je volny vykon tak dostane token. kdyz neni vykon tak se zpracuji uz jen requesty co ziskaly token.

Ved jasne ale tato cela tema je prave o tom ze co urcuje ci je vykon.

Jestli to je najaka interaktivni sluzba, tak QoS metrika by byla responzivita - tj doba vyrizeni pozadavku vetsi nez prumer = zatez je prilis vysoka. Nebo jeji 1/x prevracena hodnota - pocet odbavenych pozadavku za vterinu, coz muze byt snadnejsi k implementaci v mereni.

Realne je hranice ale velice strma - server ma vykon X a dokaze vyridit max Y requestu za vterinu. Kdyz tam budes tlacit Y+malo, tak se ti zacne prodluzovat odezva, kdyz tam budes tlacit Y+hodne, tak odezva bude treba v radu desitek vterin. Samozrejme zatez neni konstantni - ale kdyz se blizi k Y, tak je vhodne nahodit dalsi backend node a load balancovat. Problem je ze kdyz tam prijde Y+neco, tak zdanlivy vykon reseni klesne pod Y byt bude plne zatizen - protoze vykon sezerou rezijni naklady na kontext switching.

Dalsi moznosti je brat realny load OS a diskoveho subsystemu. CPU load mas work/wait/idle - zajima te zda work se blizi k 100%. Kdyz ale budes mit pomale disky, tak se to tam nikdy neprilizi, protoze jsi ve wait kolonce.. a proto musis sledovat zda jsou disky vytizeny naplno. Opacne: ze mas 100% wait neznamena ze je server zatizen - muze byt ze jen nema dost paralelnich dotazu co by sli vykonavat, protoze disk by to i dovolil.

Jako neznam sluzbu co by aktivne omezovala uzivatele, protoze provozni infrastruktura na to nestaci.. proste ve spicce to pojede vsem naprd.

[petersveter]

Jako neznam sluzbu co by aktivne omezovala uzivatele, protoze provozni infrastruktura na to nestaci.. proste ve spicce to pojede vsem naprd.

No ved to. Preto sa priklanam asi najskor k tomu co som pisal hore, ze ked mi backend vrati 5xx error, tak na minutu zacnem throttlovat nove spojenia az kym sa mi celu minutu nebudu vracat odpovede s <500 http kodom.

[mark42]

ak mas moznost ovplyvnit backend, tak je lepsie to limitovat podla konkretnej chyby 5xx - Timeout alebo Rate exceeded. Niektore chyby 5xx vobec nemusia suvusiet s pretazenim, moze to byt lubovolna interna chyba backendu.