Веб апликације се сада користе свуда, а међу свим транспортним протоколима, ХТТП заузима лавовски удео. Приликом проучавања нијанси развоја веб апликација, већина људи посвећује врло мало пажње оперативном систему где се ове апликације заправо покрећу. Раздвајање развоја (Дев) и операција (Опс) само је погоршало ситуацију. Али са порастом ДевОпс културе, програмери постају одговорни за покретање својих апликација у облаку, па је за њих веома корисно да се темељно упознају са позадином оперативног система. Ово је посебно корисно ако покушавате да примените систем за хиљаде или десетине хиљада истовремених веза.

Ограничења у веб услугама су веома слична онима у другим апликацијама. Било да су у питању балансери оптерећења или сервери базе података, све ове апликације имају сличне проблеме у окружењу високих перформанси. Разумевање ових основних ограничења и уопште како да их превазиђете помоћи ће вам да процените перформансе и скалабилност ваших веб апликација.

Ову серију чланака пишем као одговор на питања младих програмера који желе да постану добро информисани системски архитекти. Немогуће је јасно разумети технике оптимизације Линук апликација без понирања у основе њиховог рада на нивоу оперативног система. Иако постоји много типова апликација, у овој серији желим да истражујем веб-базиране апликације, а не десктоп апликације као што су претраживач или уређивач текста. Овај материјал је намењен програмерима и архитектама који желе да разумеју како функционишу Линук или Уник програми и како да их структурирају за високе перформансе.

Линук је Соба за послужење оперативни систем, а најчешће ваше апликације раде на овом ОС. Иако кажем „Линукс“, већину времена можете са сигурношћу претпоставити да мислим на све оперативне системе сличне Уник-у уопште. Међутим, нисам тестирао пратећи код на другим системима. Дакле, ако сте заинтересовани за ФрееБСД или ОпенБСД, ваши резултати могу да варирају. Када покушам нешто специфично за Линук, истичем то.

Иако ово знање можете користити да направите апликацију од нуле и она ће бити савршено оптимизована, најбоље је да то не радите. Ако напишете нови веб сервер у Ц или Ц++ за пословну апликацију ваше организације, ово може бити ваш последњи дан на послу. Међутим, познавање структуре ових апликација помоћи ће при избору постојећих програма. Моћи ћете да упоредите системе засноване на процесима са системима заснованим на нитима, као и са системима заснованим на догађајима. Разумећете и ценити зашто Нгинк ради боље од Апацхе хттпд, зашто Питхон апликација заснована на Торнаду може послужити више корисника у поређењу са Питхон апликацијом заснованом на Дјангу.

ЗероХТТПд: Алат за учење

ЗероХТТПд је веб сервер који сам написао од нуле у Ц-у као наставно средство. Нема спољне зависности, укључујући приступ Редис-у. Ми водимо сопствене Редис процедуре. Погледајте испод за више детаља.

Иако бисмо могли опширно да расправљамо о теорији, нема ничег бољег од писања кода, његовог покретања и међусобног поређења свих серверских архитектура. Ово је најочигледнији метод. Стога ћемо написати једноставан ЗероХТТПд веб сервер користећи сваки модел: заснован на процесу, базиран на нитима и заснован на догађају. Хајде да проверимо сваки од ових сервера и видимо какав је њихов учинак у поређењу једни са другима. ЗероХТТПд је имплементиран у једну датотеку Ц. Сервер заснован на догађајима укључује утхасх, одлична имплементација хеш табеле која долази у једној датотеци заглавља. У другим случајевима, нема зависности, како не би компликовали пројекат.

Постоји много коментара у коду који ће вам помоћи да разумете. Будући да је једноставан веб сервер у неколико редова кода, ЗероХТТПд је такође минимални оквир за веб развој. Има ограничену функционалност, али је способан да опслужује статичне датотеке и веома једноставне „динамичке“ странице. Морам да кажем да је ЗероХТТПд добар за учење како да креирате Линук апликације високих перформанси. Углавном, већина веб сервиса чека на захтеве, проверава их и обрађује. То је управо оно што ће ЗероХТТПд учинити. Ово је алат за учење, а не производњу. Није добар у руковању грешкама и мало је вероватно да ће се похвалити најбољим безбедносним праксама (о, да, користио сам strcpy) или паметним триковима језика Ц. Али надам се да добро ради свој посао.

ЗероХТТПд почетна страница. Може да прикаже различите типове датотека укључујући слике

Апликација за књигу гостију

Модерне веб апликације обично нису ограничене на статичне датотеке. Они имају сложене интеракције са разним базама података, кеш меморијама итд. Тако ћемо направити једноставну веб апликацију под називом „Књига гостију“ где посетиоци остављају уносе под својим именима. Уноси у књиге гостију остављени раније. Ту је и бројач посетилаца на дну странице.

Веб апликација "Књига гостију" ЗероХТТПд

Бројач посетилаца и уноси у књигу гостију се чувају у Редис-у. За комуникацију са Редис-ом се примењују сопствене процедуре које не зависе од екстерне библиотеке. Нисам велики фан увођења хомебрев кода када постоје јавно доступна и добро тестирана решења. Али сврха ЗероХТТПд-а је проучавање перформанси Линук-а и приступ спољним услугама, док опслуживање ХТТП захтева има озбиљан утицај на перформансе. Морамо у потпуности контролисати комуникацију са Редис-ом у свакој од наших серверских архитектура. У неким архитектурама користимо блокирајуће позиве, у другим користимо процедуре засноване на догађајима. Коришћење спољне Редис клијентске библиотеке неће обезбедити ову контролу. Поред тога, наш мали Редис клијент обавља само неколико функција (добијање, подешавање и повећање кључа; добијање и додавање низу). Поред тога, Редис протокол је изузетно елегантан и једноставан. Не морате чак ни да га посебно подучавате. Сама чињеница да протокол обавља сав посао у око стотину линија кода показује колико је добро осмишљен.

Следећа слика показује шта апликација ради када клијент (претраживач) захтева /guestbookURL.

Како функционише апликација за књигу гостију

Када треба да се изда страница књиге гостију, постоји један позив систему датотека за читање шаблона у меморију и три мрежна позива Редис-у. Датотека шаблона садржи већину ХТМЛ садржаја за страницу на слици изнад. Постоје и посебни чувари места за динамички део садржаја: постови и бројач посетилаца. Добијамо их од Редис-а, убацујемо их на страницу и пружамо клијенту потпуно формиран садржај. Трећи позив Редис-у се може избећи јер Редис враћа нову вредност кључа када се повећа. Међутим, за наш сервер, који има асинхрону архитектуру засновану на догађајима, много мрежних позива је добар тест за потребе учења. Дакле, одбацујемо Редис повратну вредност броја посетилаца и постављамо упит за то посебним позивом.

Архитектура сервера ЗероХТТПд

Градимо седам верзија ЗероХТТПд-а са истом функционалношћу али различитим архитектурама:

Итеративно
Форк сервер (један подређени процес по захтеву)
Пре-форк сервер (пре-форкирање процеса)
Сервер са нитима извршења (једна нит по захтеву)
Сервер са креирањем пре-треда
Архитектура заснована poll()
Архитектура заснована epoll

Меримо перформансе сваке архитектуре тако што учитавамо сервер ХТТП захтевима. Али када се пореде веома паралелне архитектуре, број упита се повећава. Тестирамо три пута и израчунавамо просек.

Методологија тестирања

ЗероХТТПд подешавање тестирања оптерећења

Важно је да приликом покретања тестова све компоненте не раде на истој машини. У овом случају, ОС има додатне трошкове планирања јер се компоненте такмиче за ЦПУ. Мерење трошкова оперативног система сваке од одабраних серверских архитектура је један од најважнијих циљева ове вежбе. Додавање више варијабли ће постати штетно за процес. Према томе, поставка на горњој слици најбоље функционише.

Шта ради сваки од ових сервера?

лоад.уникисм.нет: Овде трчимо ab, Апацхе Бенцхмарк услужни програм. Он генерише оптерећење потребно за тестирање архитектуре наших сервера.
нгинк.уникисм.нет: Понекад желимо да покренемо више од једне инстанце серверског програма. Да би то урадио, Нгинк сервер са одговарајућим подешавањима ради као балансатор оптерећења који долази ab на наше серверске процесе.
зерохттпд.уникисм.нет: Овде покрећемо наше серверске програме на седам различитих архитектура, један по један.
редис.уникисм.нет: Овај сервер покреће Редис демон, где се чувају уноси у књигу гостију и бројачи посетилаца.

Сви сервери раде на истом језгру процесора. Идеја је да се процене максималне перформансе сваке архитектуре. Пошто су сви серверски програми тестирани на истом хардверу, ово је основа за поређење. Моје тестно подешавање се састоји од виртуелних сервера изнајмљених од Дигитал Оцеана.

Шта меримо?

Можете мерити различите индикаторе. Ми процењујемо перформансе сваке архитектуре у датој конфигурацији тако што учитавамо сервере захтевима на различитим нивоима паралелизма: оптерећење расте са 20 на 15 истовремених корисника.

Резултати испитивања

Следећи графикон приказује перформансе сервера на различитим архитектурама на различитим нивоима паралелизма. И-оса је број захтева у секунди, к-оса су паралелне везе.

Испод је табела са резултатима.

захтева у секунди

paralelizam
итеративно
виљушка
пре-форк
стриминг
пре-стриминг
анкета
еполл

20
7
112
2100
1800
2250
1900
2050

50
7
190
2200
1700
2200
2000
2000

100
7
245
2200
1700
2200
2150
2100

200
7
330
2300
1750
2300
2200
2100

300
-
380
2200
1800
2400
2250
2150

400
-
410
2200
1750
2600
2000
2000

500
-
440
2300
1850
2700
1900
2212

600
-
460
2400
1800
2500
1700
2519

700
-
460
2400
1600
2490
1550
2607

800
-
460
2400
1600
2540
1400
2553

900
-
460
2300
1600
2472
1200
2567

1000
-
475
2300
1700
2485
1150
2439

1500
-
490
2400
1550
2620
900
2479

2000
-
350
2400
1400
2396
550
2200

2500
-
280
2100
1300
2453
490
2262

3000
-
280
1900
1250
2502
велико ширење
2138

5000
-
велико ширење
1600
1100
2519
-
2235

8000
-
-
1200
велико ширење
2451
-
2100

10
-
-
велико ширење
-
2200
-
2200

11
-
-
-
-
2200
-
2122

12
-
-
-
-
970
-
1958

13
-
-
-
-
730
-
1897

14
-
-
-
-
590
-
1466

15
-
-
-
-
532
-
1281

Из графикона и табеле се може видети да изнад 8000 истовремених захтева имамо још само два играча: пре-форк и еполл. Како се оптерећење повећава, сервер заснован на анкетама ради лошије од сервера за стриминг. Архитектура пре креирања нити је достојан конкурент еполл-у, сведочанство о томе колико добро Линук кернел планира велики број нити.

ЗероХТТПд изворни код

ЗероХТТПд изворни код овде. За сваку архитектуру постоји посебан директоријум.

ЗероХТТПд │ ├── 01_итеративе │ ├── маин.ц ├── 02_форкинг │ ├── маин.ц ├── 03_префоркинг │ ├── маин.ц ├── маин.ц ├── 04. 05_претхреадинг │ ├── маин.ц ├── 06_полл │ ├── маин.ц ├── 07_еполл │ └── маин.ц ├── Макефиле ├─хтмл ├─── туд│ ├─── јавно │ ├─── ту│ ├─── . пнг └── шаблони └── књига гостију └── индек.хтмл

Поред седам директоријума за све архитектуре, постоје још два у директоријуму највишег нивоа: публиц и темплатес. Први садржи датотеку индек.хтмл и слику са првог снимка екрана. Можете ставити друге датотеке и фасцикле тамо, а ЗероХТТПд би требало да сервира те статичке датотеке без икаквих проблема. Ако се путања у претраживачу поклапа са путањом у јавној фасцикли, онда ЗероХТТПд тражи датотеку индек.хтмл у овом директоријуму. Садржај за књигу гостију се генерише динамички. Има само почетну страницу, а њен садржај је заснован на датотеци 'темплатес/гуестбоок/индек.хтмл'. ЗероХТТПд лако додаје динамичке странице за проширење. Идеја је да корисници могу додати шаблоне у овај директоријум и проширити ЗероХТТПд по потреби.

Да бисте направили свих седам сервера, покрените make all из директоријума највишег нивоа - и све верзије ће се појавити у овом директоријуму. Извршне датотеке траже јавне директоријуме и директоријуме шаблона у директоријуму из којег су покренуте.

Линук АПИ

Не морате бити добро упућени у Линук АПИ да бисте разумели информације у овој серији чланака. Међутим, препоручујем да прочитате више о овој теми; постоји много референтних извора на Интернету. Иако ћемо се дотакнути неколико категорија Линук АПИ-ја, наш фокус ће бити првенствено на процесима, нитима, догађајима и мрежном стеку. Поред књига и чланака о Линук АПИ-ју, такође препоручујем читање мана за системске позиве и функције библиотеке које се користе.

Перформансе и скалабилност

Једна напомена о перформансама и скалабилности. Теоретски, нема везе између њих. Можете имати веб услугу која ради веома добро, са временом одзива од неколико милисекунди, али се уопште не повећава. Исто тако, може постојати веб апликација са лошим учинком којој је потребно неколико секунди да одговори, али се повећава за десетине да би обрадила десетине хиљада истовремених корисника. Међутим, комбинација високих перформанси и скалабилности је веома моћна комбинација. Апликације високих перформанси углавном штедљиво користе ресурсе и на тај начин ефикасно опслужују више истовремених корисника на серверу, смањујући трошкове.

ЦПУ и И/О задаци

Коначно, у рачунарству увек постоје два могућа типа задатака: за И/О и ЦПУ. Пријем захтева преко Интернета (мрежни И/О), сервирање датотека (мрежни и диск И/О), комуникација са базом података (мрежни и диск И/О) су све И/О активности. Неки упити за базу података могу бити мало ЦПУ интензивни (сортирање, просек од милион резултата, итд.). Већина веб апликација је ограничена максималним могућим И/О, а процесор се ретко користи пуним капацитетом. Када видите да неки И/О задатак користи много ЦПУ-а, то је највероватније знак лоше архитектуре апликације. То може значити да се ЦПУ ресурси троше на управљање процесима и промену контекста – а то није сасвим корисно. Ако радите нешто попут обраде слика, конверзије аудио датотека или машинског учења, апликација захтева моћне ЦПУ ресурсе. Али за већину апликација то није случај.

Сазнајте више о архитектури сервера

Извор: ввв.хабр.цом

Перформансе Линук мрежне апликације. Увод