Blogerator.org

Ексклузивни ИТ новини, рецензии и интервюта

Планиране на натоварването на сървъра

Тестването на натоварване показа, че сървърът може да обработва 10 заявки в секунда. Означава ли това, че на практика сървърът ще издържи на такова натоварване в Интернет?

В повечето случаи отговорът на този въпрос е отрицателен. Нека разгледаме по-отблизо защо.

Привидно проста задача

Даден сървър, синхронно обработка на заявки от Интернет в една нишка. Тези. сървърът може или да обработва една заявка наведнъж, или да чака нови заявки. Заявките се поставят на опашка, ако сървърът в момента е зает с обработка на друга заявка. Времето за обработка на една заявка е 100 ms.

Как така? В крайна сметка е очевидно, че за една секунда сървърът може да обработи последователно 10 заявки. Откъде идва тогава безкрайността? Факт е, че средното и равномерно натоварване са „две големи разлики“. Средното натоварване на сървъра може да бъде представено като процес на Поасон. Това означава, че в началото на първата секунда могат да дойдат наведнъж 100 заявки, а през следващите 9 секунди - нито една.

В резултат на това има 10 заявки в секунда за интервал от 10 секунди със средна сума на времето за изчакване (1.99)/100 * 100 ms = 4,95 секунди. С увеличаване на разглеждания интервал се увеличава и средното време за изчакване. Ако разгледаме средното време за изчакване на безкраен интервал от време, то то също клони към безкрайност.

Нека разгледаме други опции. Очевидно е, че при средно натоварване над 10 заявки в секунда сървърът няма да може да обработва ненужни заявки, което ще доведе до безкрайно увеличаване на опашката за изчакване на заявките.

Какво се случва, ако натоварването е под максимално допустимото? Например каква би била средната латентност при 95% натоварване, т.е. за нашия случай 9,5 заявки в секунда? Мислите за 0ms или нещо близко до това? В края на краищата, при такова натоварване сървърът трябва да е на празен ход и да чака заявки 5% от времето си.

Бързам да ви разстроя отново - средното време за изчакване в този случай ще бъде равно на 950 ms, т.е. 9,5 пъти времето, необходимо за обработка на самата заявка! Продължавай. Нека се опитаме да познаем латентността при натоварване от 90%. Не, изобщо не 900 ms, а 450 ms. Интересно.

И при какъв товар средното време за изчакване ще бъде равно на времето, необходимо за обработка на заявката? С други думи, при какво средно натоварване ще бъде средното време за реакция от сървъра 200 ms (100 ms изчакване + 100 ms обработка)? Точният отговор е 66.666. %! Дори и с една заявка в секунда, средната латентност няма да бъде нула, а някъде около 5,56 ms.

Ние не ти вярваме. Откъде идват такива странни цифри?

Числата са получени експериментално, след което е изведена формулата.

Ето една много проста функция, написана на питон, което се използва за симулиране на натоварване на сървъра и изчисляване на средната латентност.

И тук можете да проверите автентичността на горните цифри и да видите как заявките_броят влияят на точността на изчисленията. По същото време питон практика.

След като бяха получени експерименталните данни, оставаше да отговаря на формулата.

С load_factor = 1, нашата функция клони към безкрайност. Това означава, че трябва да имаме дроб, в чийто знаменател има коефициент, стремящ се към нула при load_factor = 1. Тази роля е подходяща (1 - load_factor). Продължавай. С load_factor = 0, нашата функция е нула. Това означава, че числителят на фракцията трябва да има коефициент, равен на нула, когато load_factor = 0. Очевидно това е така load_factor.

Освен това - с load_factor = 0,5, нашата функция също трябва да е равна на 0,5. Следователно, С * 0,5/(1-0,5) = 0,5 .

Откъдето C = 0,5. В резултат на това формулата приема формата:

NormalizedAvgWaitTime (load_factor) = 0.5 * load_factor/(1-load_factor)

Някъде трябва да има аналитично извеждане на тази формула посредством математически апарат Поасонов процес, но най-вероятно има твърде много матан, което не е много интересно и не е напълно ясно за основната аудитория на тази статия. Сигурен съм, че Интернет е пълен с материали по тази тема, така че всеки може да го потърси в Google самостоятелно. Може да се окаже, че математическият ми модел с формула не е съвсем правилен, но бившите ми учители на физик във всеки случай те няма да се изчервят за мен, защото същността тук, сигурен съм, е изразена съвсем правилно.

Многонишкови сървъри, сървърни клъстери и асинхронна обработка на заявки

Досега разгледахме сферичен кон във вакуум, известен още като „еднонишкови сървъри, последователно обработващи независими заявки в синхронен режим“.

На практика такива сървъри са доста редки (с изключение на времето за изпълнение на Python в Google AppEngine). Какво ще кажете за многонишковите сървъри, сървърните клъстери и други асинхронни node.js?

Това е много просто - горната формула също работи за тях. Просто трябва да забравите за подробностите за изпълнението и да представите нашия сървър или клъстер във формуляра Черна кутияИ след това определете максималното натоварване, което тази черна кутия може да издържи, за да се калибрира правилно load_factor във формулата. Максималното натоварване, изразено в заявки в секунда, може да бъде определено по следния начин: изпращаме нашата черна кутия във възможно най-кратки срокове (колкото по-малко, толкова по-точен е резултатът) фиксиран брой реални заявки (толкова повече, колкото по-точен е резултатът) и времето, когато всички те са обработени правилно. След това разделяме броя на обработените заявки на времето.

Това е желаното максимално натоварване на нашата система, спрямо което се калибрира load_factor .

Теория на опашките

Следователно има значително подобрен модел, който може да емулира няколко сървъра (многоканален QS) с няколко режима на изпращане на заявки от опашката към сървърите - най-малко натоварен, случайни и кръгла робинка —Вижте кода и резултатите тук: ideone.com/DXB9n .

За режима на обиколка можете също да променяте броя на опашките (клиенти). За другите режими броят на клиентите няма значение.

Как правилно да планирате натоварването на сървъра?

На този етап трябва да ви е ясно, че резултатите от типично изпитване на натоварване преди пускане в производство не отразяват съвсем правилно обективната реалност. Основният проблем е, че потокът от тестови заявки не е процесът на Poisson, който сървърът е предназначен да срещне в производството. Но това е лесно поправимо. Достатъчно е да се намери максималното натоварване, което системата може да издържи съгласно схемата, описана в предишния параграф.

След това, използвайки формулата, изчислявате допустимия товар в производството за даденото средно време за изчакване на заявката. Например за максимално натоварване от 1000 qps и средно време за изчакване на заявката, равно на 100% от времето за обработка на заявката:

1 = 0,5 * фактор на натоварване/(1-фактор на натоварване) => фактор на натоварване = 1/1,5 = 2/3.

Тогава допустимото натоварване е: 1000 * 2/3 = 666.666. qps .

Многонишкови програми

Можете ли да използвате това, което току-що научихте, за да изчислите средното време за изчакване за защитен със заключване споделен ресурс в многонишкова програма? Отговорът е не, защото процесът на достъп до споделен ресурс от малък брой нишки (например по-малко от хиляда) не може да бъде приближен Поасонов процес.

В многонишковите програми максималното натоварване на достъпа до споделен ресурс винаги е известно - то е пропорционално на максималния брой нишки, които могат да получат заключване. Освен това, за най-простото изпълнение на брави под формата на FIFO опашка от блокирани нишки, винаги е известно максималното време на изчакване - то е пропорционално на максималния брой нишки и времето на задържане на ключалката.

Винаги наблюдавайте натоварването на системи, които обработват заявки, които са с времето на Поасон. Такива системи включват всички системи с потенциално голям брой потребители. Например всички сървъри, свързани към Интернет.

Моля, кажете ми, трябва да разположа 2-3 онлайн магазина в prestashop, хостера се интересува от:

"За какъв товар говорим? За колко заявки в секунда? От какво ниво на устойчивост на грешки имате нужда?"

телепати на почивка в Бали слънчеви бани. Как можем да знаем това?