A feldolgozási kérelmek sebességének korlátozása nginxben
- 11.07.17 07:57 •
- légy •
- # 329876 •
- Habrahabr •
- Fordítás •
- 11 •
- 4500
- ugyanaz, mint Forbes, csak jobb.
Wonderlane képe
NGINX nagyszerű! Itt csak a feldolgozási kérelmek gyorsaságát korlátozó dokumentuma tűnik számomra, hogyan mondhatnám ezt, némileg korlátozott. Ezért úgy döntöttem, hogy ezt a kézikönyvet a NGINX-ben a feldolgozási kérelmek (sebességmélyítés) és a forgalomformálás (forgalomformálás) sebességének korlátozásáról írom.
- írja le a NGINX iránymutatásait,
- megérteni a NGINX elfogadási / elutasító logikával,
- szemléltesse a különböző helyszínek forgalmának feldolgozását.
Ezenkívül létrehoztam egy GitHub tárat és egy Docker képet. amivel kísérletet tehet és reprodukálhatja az ebben a cikkben megadott teszteket. A gyakorlatban mindig könnyebb megtanulni.
Az NGINX irányelvei a feldolgozási kérelmek sebességének korlátozására
Ebben a cikkben a ngx_http_limit_req_moduleról beszélünk. amelyben a limit_req_zone irányelveket hajtják végre. limit_req. limit_req_status és limit_req_level. Lehetővé teszik, hogy ellenőrizze az elutasított kérelmek HTTP állapotkódjának értékét, valamint a hibák naplózását.
Leggyakrabban a lekérdezés elutasításának logikájába zavarják.
Először meg kell értened a limit_req direktívát. amely zóna paramétert igényel. Opcionális paramétereket is tartalmaz a burst és a nodelay számára.
A következő fogalmakat használjuk itt:
a kitörés opcionális paraméter. A telepítés után meghatározza a megteendő alapsebesség-határértéket meghaladó feldolgozásra kerülő kérelmek számát. Fontos megérteni, hogy a kitörés a kérelmek számának abszolút értéke, nem pedig a sebesség.
Hogyan dönt a NGINX, hogy elfogadja vagy elutasítja-e a kérelmet?
A zóna beállításakor a sebesség beállítása történik. Például 300r / m 300 kérés percenként fogadható el, másodpercenként pedig 5r / s - 5 kérelem.
- limit_req_zone $ request_uri zóna = zóna1: 10 m arány = 300r / m;
- limit_req_zone $ request_uri zóna = zóna2: 10 m arány = 5 / s;
Fontos megérteni, hogy ez a két zóna azonos határokkal rendelkezik. Az NGINX frekvenciaparaméter segítségével kiszámolja a frekvenciát, és ennek megfelelően azt az intervallumot, amely után új kérést fogadhat el. Ebben az esetben az NGINX egy szivárgó vödör nevű algoritmust fog használni.
Az NGINX 300r / m és az 5r / s esetén ugyanazok vannak: minden kérés 0,2 másodpercenként kihagyja. Ebben az esetben az NGINX minden 0.2 másodpercenként zászlót állít be, hogy lehetővé tegye a kérés fogadását. Amikor egy kérés érkezik erre a zónára, az NGINX eltávolítja a zászlót, és feldolgozza a kérést. Ha kap egy újabb kérést, és az időzítő idő csomagok között, még mindig nem működik, a kérelmet el kell utasítani a status code 503. Ha az idő letelt, de a zászló már be van állítva, hogy lehetővé tegyék a befogadási értékét, semmilyen művelet nem hajtható végre.
Szükség van a feldolgozási kérelmek sebességének korlátozására és a forgalom alakítására?
Beszéljünk a burst paraméterről. Képzeld el, hogy a zászló, amelyről beszéltünk, nagyobb értéket vehet fel. Ebben az esetben ez tükrözi azon kérelmek maximális számát, amelyeket az NGINX egyetlen sorozatban elszalaszt.
Most ez nem egy "vödör vödör", egy "token vödör". A sebességparaméter meghatározza a kérések közötti időintervallumot, de nem a true / false típusú típusú tokennel foglalkozunk, hanem a 0-1 + burst számlálóval. A számláló növekszik minden egyes alkalommal, amikor a kiszámított időintervallum elhalad (az időzítő elindul), elérve a maximális értéket b + 1-ben. Hadd emlékeztessem még egyszer: a kérések száma, nem pedig a továbbítás sebessége.
Amikor új kérés érkezik, az NGINX ellenőrzi a token elérhetőségét (számláló> 0). Ha a token nem érhető el, a kérés elutasításra kerül. Ellenkező esetben a kérelmet elfogadják és feldolgozzák, és a jelzőt elfogyasztják (a számlálót egyenként csökkentik).
Nos, ha nincsenek feltöltött tört jelzők, az NGINX elfogadja a kérést. De mikor fog feldolgozni?
Hoztunk létre egy határ 5R / s, míg nginx fogadjon kéréseket meghaladó, ha van egy tört-tokenek állnak rendelkezésre, de elhalasztja annak feldolgozása, hogy fenntartsa a beállított sebességet. Vagyis ezek a sorozatok kéréseinek feldolgozása valamilyen késéssel vagy késleltetéssel történik.
Más szavakkal, az NGINX nem lépi túl a zónára vonatkozó határértéket, de további kéréseket helyez a várakozási sorban, és késleltetéssel feldolgozza azokat.
Íme egy egyszerű példa: azt mondjuk, hogy van 1r / s határ és 3 sorozata. Mi történik, ha az NGINX egyszerre 5 kérelmet kap?
- Az elsőt elfogadják és feldolgozzák.
- Mivel legfeljebb 1 + 3 engedélyezett, egy kérést azonnal el kell utasítani az 503-as állapotkóddal.
- A három fennmaradó egységet egyenként, de nem azonnal kell feldolgozni. Az NGINX 1r / s sebességgel ugrik. a megállapított határon belül marad, és feltéve, hogy nem érkeznek új kérelmek, amelyek szintén használják a kvótát. Amikor a sor üres, a számláló újra elkezd növekedni (a token kosár elkezd kitölteni).
Abban az esetben, nginx alkalmazás proxy szerver mögött található ez szolgáltatásokat kap kéréseket sebesség 1r / s, és nem tud a forgalom élénk, simított a proxy szerver.
Tehát csak forgalmi formázást állítottunk be, késleltetve a lekérdezések tördelését és az adatáramlást.
a nodelay azt mondja a NGINX-nak, hogy be kell fogadnia a csomagokat a burst érték által meghatározott ablakban. és azonnal feldolgozza azokat (valamint a normál kéréseket).
Ennek eredményeképpen a forgalmi bomlások továbbra is eljutnak a NGINX mögötti szolgáltatásokhoz, de ezek a burstok a burst értékét korlátozzák.
A kérelmek feldolgozásához szükséges sebességkorlátozások megjelenítése
Mivel úgy vélem, hogy ez a gyakorlat sok mindent meg tud emlékezni, egy kis Docker képet készítettem a NGINX-szel a fedélzeten. Vannak konfigurált erőforrások, amelyekre a feldolgozási kérelmek sebességének korlátozására szolgáló különböző lehetőségek kerülnek megvalósításra: alapeseti korlátozással, sebességkorlátozással, burst használatával. valamint burst és nodelay. Lássuk, hogyan működnek.
Itt egy meglehetősen egyszerű NGINX konfigurációt használunk (ez a Docker-képben is megtalálható, amely link a cikk végén található):
Teszt konfiguráció NGINX különféle lehetőségekkel a feldolgozási kérelmek sebességének korlátozására
Minden tesztben, ezzel a konfigurációval együtt, 10 párhuzamos kérést küldünk egyszerre.
Megtudjuk, mit:
- hány kérelmet elutasítanak a sebességhatárok miatt?
- Mi a beérkezett kérelmek feldolgozási sebessége?
Az erőforráshoz 10 egyidejű kérést készítünk a feldolgozási kérelmek sebességének korlátozásával
10 egyidejű kérés egy erőforráshoz, amelynek sebességkorlátja a kérések feldolgozásához
Konfigurációnkban 30 kérés percenként engedélyezett. De ebben az esetben 10-ből 9-et elutasítanak. Ha alaposan elolvassa az előző szakaszokat, az NGINX viselkedése nem fog meglepődni: 30r / m azt jelenti, hogy csak egy kérés érhető el 2 másodpercen belül. Példánkban 10 kérelem érkezik egyszerre, az egyiket kihagyjuk, és a másik kilencet elutasítjuk, mert az NGINX látható, mielőtt az időzítő engedélyezi a következő kérést.
Az ügyfelek / végpontok iránti aprólékos kérdéseket túl fogom élni
Jó! Ezután hozzáfűzzük az argumentum törését = 5. amely lehetővé teszi a NGINX számára, hogy a zónák ezen végpontjaihoz tartozó kis kéréscsomagokat átugorja a feldolgozási kérelmek sebességének korlátozásával:
10 párhuzamos kérés az erőforráshoz, az argumentum törés = 5
Mi történt itt? Amint azt elvárnánk, a felrobbantott érveléssel 5 további kérés érkezett, és a beérkezett kérelmek arányát a teljes számukra 1/10-ról 6/10-ra növeltük (a többit elutasították). Könnyű látni, hogy az NGINX frissíti a tokeneket és feldolgozza a fogadott kéréseket - a kimenő sebesség 30r / m-re korlátozódik. ami 2 másodpercenként egy kérésnek felel meg.
Az első kérésre adott válasz 0,2 másodperc múlva jelenik meg. Az időzítő 2 másodperc elteltével indul, az egyik folyamatban lévő kérés feldolgozása, és az ügyfél megkapja a választ. Az út oda-vissza útja 2,02 másodperc volt. További 2 másodperc elteltével az időzítő újra aktiválódik, lehetőséget adva egy másik kérelem feldolgozására, amelyet 4,02 másodperces teljes utazási idővel adnak vissza. És így tovább ...
Így a felszakítási argumentum lehetővé teszi, hogy az NGINX kérések feldolgozásának sebességét korlátozzák egy egyszerű küszöbszűrőből egy forgalombizálóhoz.
A szerverem ellenáll az extra terhelésnek, de a feldolgozási kérelmek sebességkorlátját szeretném használni a túlterhelés megakadályozása érdekében
Ebben az esetben a nodelay argumentum hasznos lehet. Küldje el ugyanazt a 10 lekérdezést a végponthoz a burst beállítással = 5 nodelay:
10 párhuzamos kérés az erőforráshoz, az argumentum burst = 5 nodelay
Ahogy a várakozások szerint a robbanás = 5. ugyanolyan arányban lesz a 200-as és az 503-as státuszkód. De a kimenő sebesség nem korlátozódik egyetlen kérésre 2 másodpercenként. Amíg rendelkezésre állnak feltörési tokenek, a bejövő kérelmeket azonnal elfogadják és feldolgozzák. Az időzítő sebessége még mindig fontos a töredékjelek számának feltöltése szempontjából, de a késedelem nem vonatkozik a beérkezett kérelmekre.
Összegezzük az eredményeket
Próbáljuk megnézni, hogy a NGINX hogyan fogadja be a beérkező kéréseket és feldolgozza azokat a sebességparaméterek alapján. tört és csomó.
Ahhoz, hogy a dolgok egyszerű, megjeleníti a beérkező kérések (amelyeket aztán elutasították vagy elfogadták és feldolgozott) A meghatározott beállítások idővonal zóna bontották egyenlő szegmensében a pickup időzítőt. Az időintervallum abszolút értéke nem jelentős. Az NGINX által minden lépésben feldolgozható kérések száma fontos.
Itt van a forgalom, amelyet a kérések feldolgozásához szükséges sebességkorlátozás különböző beállításain keresztül futtathatunk:
A bejövő kérelmek és lekérdezési feldolgozási sebességkorlátozások a zónában
Fogadott és elutasított kérelmek (a burst beállítás nincs megadva)
Burkolat nélkül (azaz ha burst = 0), az NGINX végrehajtja a sebességkorlátozó funkcióját. A kérelmeket azonnal feldolgozzák vagy elutasítják.
Ha azt akarjuk, hogy a kis pörgős forgalmat, például, hogy dozagruzit teljesítményt a megállapított korlátot, akkor adjunk hozzá egy tört érv. ami a rendelkezésre álló burstjelzőkön belül érkezett kérelmek feldolgozásának késleltetését jelenti:
Elfogadott, késleltetett és elutasított kérelmek (burst használatával)
Látjuk, hogy az elutasított kérelmek száma csökkent. Csak azokat a nagysebességű kéréseket utasították el, amelyek akkor jöttek, amikor nem állt rendelkezésre burst-token. Ilyen beállításokkal az NGINX teljes körű forgalmi formát valósít meg.
Végül nginx lehet használni, ami végül a kevésbé stabil kimenő díjat forgalomirányítási korlátozásával kérés löketméret (tört), de részben a lökésszerű kérelmek elérik rakodók (upstream vagy helyi), de javítja a hálózat késleltetését ( ha természetesen kezelheti ezeket a további kéréseket):
Elfogadott, feldolgozott és visszautasított kérelmek (a csomópontos csíkot használják)
Játssz a sebességkorlátozási kérelmekkel
Most, hogy jobban biztosítsák a megértése a vitaanyagot, akkor vizsgálja meg a kódot másolja az adattár kísérletezni és képzett Docker-módon:
Nem értem, miért, a rövidség kedvéért, a fogalom-korlátozás kifejezés fordítására, ne dobd le az utolsó két szót. Úgy gondolom, hogy mindenki megérti, milyen "sebességkorlátozás" a nginx kontextusában a kérdés. Nincs más értelmezés és esetleges kétértelműség.
Számomra a sebesség limit_rate (az előbbin nginx-ben jelent meg). Az eredeti úgy tűnik, túl ügyetlenül írt ... helyettesítése fogalmak)), hogy még mindig korlátozza a cikket _not_ ponyatno_. Sőt, írsz a forgalom alakításáról, de semmi sem)))