- 07.11.17 07:57 •
- olemskoi •
- • # 329876
- • Habrahabr
- превод •
- 11 •
- 4500
- като Forbes, само по-добре.
Фото Потребителят Wonderlane, Flickr
Nginx страхотно! Това е само на неговите документи да се ограничи изпълнението на заявката Струваше ми се, като че ли да се каже, малко по-ограничен. Затова реших да напиша това ръководство за ограничаване на скоростта на обработка на заявката (процент-варосване) и трафик оформянето (трафик оформяне) в Nginx.
- Опишете директиви Nginx
- справят с приемане / отхвърляне-логика Nginx,
- визуализират обработка изблици на трафик на различни настройки.
Освен това, съм създал GitHub хранилище-и Docker изображение. с която можете да експериментирате и да играе в тази статия тестове. Винаги е по-лесно да се учи, като направите.
Nginx скоростта на обработка на заявката ограничаването
В тази статия ще говорим за ngx_http_limit_req_module. където осъществява директива limit_req_zone. limit_req. limit_req_status и limit_req_level. Те ви позволяват да контролирате HTTP заявка ключ стойността на код за състоянието отхвърлен (отхвърлени) искания, както и сеч на тези неуспехи.
Най-често тя е объркана логика, като е отхвърлил искането.
Първо трябва да се разбере директива limit_req. което изисква настройка зона. Тя също има незадължителни параметри и избухна nodelay.
Следните понятия са използвани тук:
разрушаване - по избор. Когато е настроен, той определя броя на исканията, които могат да се обработват над установеното ограничение на скоростта база. Важно е да се разбере, че спукването - това е абсолютната стойност на броя на заявките, не се ускори.
Как Nginx взема решение за приемане или отхвърляне на искането?
При определянето на зона скоростта му е дадено. Например, при 300R / m ще бъде 300 искания за минута, и най-5R / и - 5 заявки в секунда.
- limit_req_zone $ REQUEST_URI зона = Зона 1: скорост 10m = 300R / m;
- limit_req_zone $ REQUEST_URI зона = ZONE2: скорост 10m = 5 / и;
Важно е да се разбере, че тези две зони имат същите ограничения. Използването на скоростта на параметър Nginx изчислява честотата и, съответно, на интервала, след който ново искане може да бъде приет. В този случай Nginx ще използва алгоритъм, наречен "спукан кофа» (спукан кофа).
За Nginx 300R / м и 5г / и са идентични: той ще пропусне една молба на всеки 0.2 с. В този случай, на всеки 0.2 секунди Nginx ще определят флаг за разрешаване на получаване на искането. Когато дойде заявка подходящ за тази зона, Nginx премахва флага и дръжки на искането. Ако получите друго искане, и таймерът отброява времето между пакети, все още не работи, искането се отхвърля с код за състоянието на 503. Ако времето е изтекло, но флага вече е настроена да позволи стойността на приемане, ще се извършва никакво действие.
Трябва ли да задава въпроси за ограничение на скоростта и оформянето на трафика?
Говорете за спука параметър. Представете си, че знамето, което споменахме по-горе, може да се настрои на по-голяма от един. В този случай, това ще се отрази на максимален брой заявки, които Nginx трябва да мине в рамките на един пакет (разрушаване).
Сега това не е "спукан кофа", "маркер кошница» (знак кофа). параметър Rate определя времеви интервал между искания, но ние не се занимаваме с жетон типа вярно / невярно, и брояча от 0 до 1 + разрушаване. Броячът се увеличава всеки път, когато тя преминава изчисленото интервал от време (таймера се задейства), достигайки максимална стойност на Ь + 1. Нека ви напомня отново: спука - това е броят на исканията, а не със скоростта на тяхното преминаване.
Когато пристигне ново искане, Nginx проверява наличието на маркера (брояч> 0). Ако означението не е на разположение, искането се отхвърля. В противен случай, искането е получено и обработено и белегът се счита за да се консумира (брой се намалява с един).
Е, ако има неусвоени спукване жетони, Nginx ще поиска. Но когато той се обработва?
Ние сме установили лимит от 5г / сек, а Nginx приема заявки за по-големи от това, ако има на разположение Избухване-жетони, но ще отложи неговата обработка, така че да се поддържа зададената скорост. Това означава, че се спука-исканията ще бъдат обработени незабавно и ще завършат с изчакване.
С други думи, Nginx няма да надвишат указания лимит за зоната и сложи допълнителни заявки на опашката и ги обработват с известно закъснение.
Един прост пример: да кажем, че ние се 1R / сек и избухна граница е 3. Какво ще стане, ако вие получавате само 5 Nginx искания?
- Първият ще бъде получено и обработено.
- Тъй като вече не е позволено да се 1 + 3, искането е отхвърлено веднага с код за състоянието на 503.
- Останалите три ще бъдат обработени една след друга, но не веднага. Nginx ги пропуснете с 1г / и скорост. макар и да остава в рамките на установения срок, и при условие, че няма нови искания ще бъдат получени, който също се използва квота. Когато опашката е празна, контра избухване (спука брояч) отново започва да се покачва (старт маркер кошница попълнено).
В случай на използване Nginx като прокси сървър, намиращ се зад него услуги ще получите по заявка с скорост 1г / и и не знам за залпове трафик, изгладени от прокси сървъра.
Така че, ние току-що създадена трафик оформяне, като се прилага незабавно да контролира привеждането на изблици на искания и данни поток.
nodelay Nginx казва, че той трябва да получава пакети в рамките на прозореца определя от стойността на разрушаване. и веднага ги (както и обичайните искания) процес.
В резултат на това трафик шпайкове все още ще достигнат до услуги, намиращи се зад Nginx, но тези изблици ще бъдат ограничени до стойността на разрушаване.
ограничаване на скоростта обработка Визуално заявка
Защото вярвам, че практиката е много полезно помня какво друго, аз направих една малка Docker изображение с Nginx на борда. Има персонализирани ресурси, за които различни изпълнения се прилагат за ограничаване на скоростта за обработка на заявката: основа ограничение с нивото на ограничение използване на разрушаване. както и разрушаване и nodelay. Нека да видим как те работят.
Той използва сравнително проста конфигурация Nginx (тя също трябва да Docker изображение, връзка към който може да се намери в края на статията):
Тест конфигурация Nginx с различни изпълнения на ограничаване на скоростта за обработка на заявката
Във всички тестове с използването на тази конфигурация, ние ще се изпращат едновременно на 10 паралелни запитвания.
Нека разберем тук, че:
- колко молби ще бъдат отхвърлени поради ограничението на скоростта?
- Каква е скоростта на обработка на постъпилите искания?
Как за 10 едновременни заявки към скорост на обработка на заявката ограничение на ресурсите
10 едновременни заявки към скорост на обработка на заявката ограничение на ресурсите
30 заявки в минута са позволени в нашата конфигурация. Но в този случай 9 от 10, ще бъдат отхвърлени. Ако сте прочели предишните раздели, това поведение Nginx няма да бъде изненада за теб: 30R / m означава, че проходът ще бъде само едно искане на всеки 2 секунди. В нашия пример, 10 искания пристигат едновременно, един се пропуска, а останалите девет са отхвърлени, защото са видели Nginx преди таймерът за сън, което позволява на следващото искане.
Аз отивам през малки изблици на заявките на клиентите / крайните точки
Добре! След това добавете аргумента избухна = 5. който ще премине Nginx малки изблици на заявки към дадена крайна точка зона с ограничение на скоростта за обработка на заявката:
10 едновременни заявки към ресурсите, с аргумент разрушаване = 5
Какво се е случило тук? Както може би очаквате, с спука аргумент е направена на 5 допълнителни искания, и сме подобрили съотношението на получените заявки до общия брой от 01.10-06.10 (останалите бяха отхвърлени). Там ясно се вижда като Nginx актуализира жетона и обработва постъпилите искания - ограничена скорост изходящ 30R / м. това се равнява на една молба на всеки 2 секунди.
Отговорът на първата заявка, се връща през 0.2 секунди. Таймерът се активира след 2 секунди, единият от чакащата заявка се обработва, и клиентът се връща. Общото време, прекарано на пътя напред и назад, беше 2.02 секунди. След още 2 секунди таймер се активира отново, което дава възможност за обработка на следващата заявка, че се връща на общото време, по начин, равна на 4.02 секунди. И така нататък, и така нататък ...
По този начин, избухна спор позволява трансформиране на заявки за обработка на ограничаване на скоростта, система Nginx от обикновен праг филтър в шейпър на трафик.
Моят сървър оцелее допълнителна тежест, но бих искал да използвам заявки ограничават скоростта, за да се предотврати претоварването
В този случай, може да е полезно аргумент nodelay. Нека да изпращат едни и същи 10 искания крайна точка да се спука настройка = 5 nodelay:
10 едновременни заявки към ресурсите, с аргумент разрушаване = 5 nodelay
Както се очаква от спукването = 5. ние ще имаме същото съотношение на кодове за състоянието на 200 и 503 е. Но изходяща скорост вече не се ограничава само до едно искане на всеки 2 секунди. Докато налични спукване жетони, входящи заявки ще се приемат и обработват веднага. Отговор на таймера скорост все още е важно от гледна точка на размера на попълване на разпукване жетони, но са получили искания да забавят вече не се прилага.
За да обобщим
Опитайте се да се визуализира как Nginx получава входящи заявки и ги преработва въз основа на параметрите на курс. спука и nodelay.
За да опростим нещата, показва броя на постъпващите заявки (които след това се отхвърлят или приемат и обработват) на дефинирани настройки график зона разделен на равни сегменти на таймера за пикап. Абсолютната стойност на интервала от време, не е от съществено значение. Важно е да се броят на исканията, които могат да обработват Nginx на всяка стъпка.
Тук на трафика, който ще карам през отделните заявки процес на определяне на ограничение на скоростта:
Входящите искания и ограничаване на ефективността на заявките, определени за зоната
Приетите и отхвърлени исканията (спука не е зададена)
Без разрушаване (т.е., когато нахлу = 0) Nginx служи като ограничител на скоростта. Исканията се обработват незабавно или веднага отхвърлени.
Ако искаме да се даде възможност на малките изблици на трафик, например, да dozagruzit мощност в рамките на установения срок, а след това можете да добавите аргумент разрушаване. което означава забавяне в обработката на заявките, получени в рамките на наличните спукване символи:
Взети взето със закъснение и отхвърлени искания (с помощта на взрив)
Ние виждаме, че общият брой на отхвърлените молби е намалял. Само тези, бяха отхвърлени исканията надвишава зададената скорост, която влезе в моментите, когато не е на разположение на разпукване жетони. С тези настройки Nginx извършва пълно оформяне на трафика.
И накрая, Nginx може да се използва, което в крайна сметка ще доведе до по-малко стабилен изходяща скорост за управление на трафика чрез ограничаване размера на искането взрив (разрушаване), но ще бъде частично с изблици на искания достигат манипулатори (нагоре или местни), но ще се подобри забавянето на мрежата ( ако, разбира се, можете да се справят с тези допълнителни заявка):
Отнети, обработват и отхвърлени заявки за реклами (разрушаване използвани за nodelay)
Играйте с ограничение скоростта на обработка на заявката
Сега, за да се осигури по-добро разбиране на концепцията, можете да се разгледа кода, копирайте хранилището да експериментират с обучен и Docker посоки:
Аз не виждам защо за краткост в превода на термина, ограничаващ скоростта не отхвърлят последните две думи. Мисля, че всеки разбира какъв вид "ограничение на скоростта" в контекста на Nginx въпрос. Никоя друга възможно двусмислие при тълкуването и не трябва да бъде.
За мен, скоростта - това limit_rate (преди тя да се появи в Nginx). В оригинала, изглежда твърде несръчно написана ... подмяната на понятия)), че все още се ограничи върху вашата статия _not_ ponyatno_. Освен това, можете да напишете какво оформянето на трафик, и за него нищо)))
Свързани статии