Linux желілік қолданбасының өнімділігі. Кіріспе

Веб-қосымшалар қазір барлық жерде қолданылады және барлық тасымалдау протоколдарының ішінде HTTP негізгі үлесті алады. Веб-қосымшаларды әзірлеудің нюанстарын зерттегенде, адамдардың көпшілігі осы қолданбалар нақты жұмыс істейтін операциялық жүйеге өте аз назар аударады. Әзірлеудің (Dev) және операциялардың (Ops) бөлінуі жағдайды тек нашарлатты. Бірақ DevOps мәдениетінің өркендеуімен әзірлеушілер өздерінің қолданбаларын бұлтта іске қосуға жауапты болады, сондықтан олар үшін операциялық жүйенің серверімен мұқият танысу өте пайдалы. Бұл мыңдаған немесе ондаған мың бір уақыттағы қосылымдар үшін жүйені орналастыруға әрекеттенсеңіз, әсіресе пайдалы.

Веб қызметтеріндегі шектеулер басқа қолданбалардағы шектеулерге өте ұқсас. Жүктеме теңестірушілер немесе дерекқор серверлері болсын, осы қолданбалардың барлығында өнімділігі жоғары ортада ұқсас мәселелер бар. Осы іргелі шектеулерді және жалпы оларды қалай жеңуге болатынын түсіну веб-қосымшаларыңыздың өнімділігі мен ауқымдылығын бағалауға көмектеседі.

Мен бұл мақалалар топтамасын жақсы хабардар жүйелер сәулетшісі болғысы келетін жас әзірлеушілердің сұрақтарына жауап ретінде жазып отырмын. Linux қолданбаларын оңтайландыру әдістерін олардың операциялық жүйе деңгейінде қалай жұмыс істейтіндігінің негіздеріне сүңгусіз анық түсіну мүмкін емес. Қолданбалардың көптеген түрлері бар болса да, бұл серияда браузер немесе мәтіндік редактор сияқты жұмыс үстелі қолданбаларынан гөрі веб негізіндегі қолданбаларды зерттегім келеді. Бұл материал Linux немесе Unix бағдарламаларының қалай жұмыс істейтінін және олардың жоғары өнімділік үшін құрылымын түсінгісі келетін әзірлеушілер мен сәулетшілерге арналған.

Linux бұл сервер бөлмесі операциялық жүйе және сіздің қолданбаларыңыз көбінесе осы ОЖ-да жұмыс істейді. Мен «Linux» десем де, көп жағдайда Unix-ке ұқсас операциялық жүйелердің барлығын айтамын деп сенімді түрде болжауға болады. Дегенмен, мен ілеспе кодты басқа жүйелерде тексерген жоқпын. Сонымен, егер сізді FreeBSD немесе OpenBSD қызықтырса, нәтижелеріңіз әртүрлі болуы мүмкін. Мен Linux-қа тән нәрсені қолданып көргенде, мен оны көрсетемін.

Сіз бұл білімді нөлден бастап қолданба жасау үшін пайдалана аласыз және ол тамаша оңтайландырылғанымен, мұны жасамағаныңыз жөн. Ұйымыңыздың іскери қолданбасы үшін C немесе C++ тілінде жаңа веб-сервер жазсаңыз, бұл жұмыстағы соңғы күніңіз болуы мүмкін. Дегенмен, осы қолданбалардың құрылымын білу бар бағдарламаларды таңдауға көмектеседі. Сіз процеске негізделген жүйелерді ағынға негізделген жүйелермен, сондай-ақ оқиғаға негізделген жүйелермен салыстыра аласыз. Сіз Nginx неге Apache httpd қарағанда жақсы жұмыс істейтінін, Tornado негізіндегі Python қолданбасы Django негізіндегі Python қолданбасымен салыстырғанда неге көбірек пайдаланушыларға қызмет көрсете алатынын түсінесіз және бағалайсыз.

ZeroHTTPd: Оқу құралы

ZeroHTTPd бұл мен C тілінде нөлден бастап оқыту құралы ретінде жазған веб-сервер. Оның Redis-ке кіруді қоса, сыртқы тәуелділіктері жоқ. Біз өзіміздің Redis процедураларын орындаймыз. Қосымша мәліметтер алу үшін төменде қараңыз.

Біз теорияны әрі қарай жалғастыра алатын болсақ та, код жазу, оны іске қосу және барлық сервер архитектурасын салыстыру сияқты ештеңе жоқ. Бұл ең айқын әдіс. Сондықтан біз әрбір үлгіні пайдалана отырып қарапайым ZeroHTTPd веб-серверін жазамыз: процеске негізделген, ағынға негізделген және оқиғаға негізделген. Осы серверлердің әрқайсысын тексеріп көрейік және олардың бір-бірімен салыстырғанда қалай жұмыс істейтінін көрейік. ZeroHTTPd бір C файлында жүзеге асырылады.Оқиғаға негізделген сервер кіреді уташ, бір тақырып файлында келетін тамаша хэш кестесін іске асыру. Басқа жағдайларда жобаны қиындатпау үшін тәуелділіктер болмайды.

Кодта түсінуге көмектесетін көптеген түсініктемелер бар. Бірнеше код жолындағы қарапайым веб-сервер бола отырып, ZeroHTTPd сонымен қатар веб-әзірлеудің минималды негізі болып табылады. Оның шектеулі функционалдығы бар, бірақ статикалық файлдарға және өте қарапайым «динамикалық» беттерге қызмет көрсетуге қабілетті. Мен ZeroHTTPd өнімділігі жоғары Linux қосымшаларын жасауды үйрену үшін жақсы екенін айтуым керек. Жалпы алғанда, веб-қызметтердің көпшілігі сұрауларды күтеді, оларды тексереді және өңдейді. ZeroHTTPd дәл осылай жасайды. Бұл өндіріс емес, оқу құралы. Бұл қателерді өңдеуде жақсы емес және ең жақсы қауіпсіздік тәжірибелерімен мақтана алмайды (иә, мен қолдандым strcpy) немесе Си тілінің ақылды айлалары.Бірақ ол өз жұмысын жақсы атқарады деп үміттенемін.

Linux желілік қолданбасының өнімділігі. Кіріспе
ZeroHTTPd басты беті. Ол әртүрлі файл түрлерін, соның ішінде кескіндерді шығара алады

Қонақ кітапшасы қолданбасы

Қазіргі веб-қосымшалар әдетте статикалық файлдармен шектелмейді. Олардың әртүрлі дерекқорлармен, кэштермен және т.б. күрделі өзара әрекеттесулері бар. Сондықтан біз «Қонақ кітабы» деп аталатын қарапайым веб-қосымшаны жасаймыз, мұнда келушілер өз аттарының астында жазбалар қалдырады. Қонақ кітапшасы бұрын қалдырылған жазбаларды сақтайды. Сондай-ақ беттің төменгі жағында келушілер есептегіші бар.

Linux желілік қолданбасының өнімділігі. Кіріспе
ZeroHTTPd «Қонақ кітабы» веб-қосымшасы

Келушілер есептегіші мен қонақтар кітабының жазбалары Redis ішінде сақталады. Redis-пен байланысу үшін жеке процедуралар орындалады, олар сыртқы кітапханаға тәуелді емес. Мен жалпыға қолжетімді және жақсы тексерілген шешімдер болған кезде homebrew кодын шығарудың үлкен жанкүйері емеспін. Бірақ ZeroHTTPd мақсаты Linux өнімділігін және сыртқы қызметтерге қол жеткізуді зерттеу болып табылады, сонымен бірге HTTP сұрауларына қызмет көрсету өнімділікке айтарлықтай әсер етеді. Біз әрбір сервер архитектурасындағы Redis-пен байланысты толық бақылауымыз керек. Кейбір архитектурада біз блоктау қоңырауларын қолданамыз, басқаларында оқиғаға негізделген процедураларды қолданамыз. Сыртқы Redis клиент кітапханасын пайдалану бұл басқаруды қамтамасыз етпейді. Сонымен қатар, біздің кішкентай Redis клиентіміз тек бірнеше функцияларды орындайды (кілт алу, орнату және ұлғайту; массив алу және қосу). Сонымен қатар, Redis протоколы өте талғампаз және қарапайым. Оны арнайы үйретудің де қажеті жоқ. Протоколдың жүзге жуық код жолындағы барлық жұмысты орындауының өзі оның қаншалықты жақсы ойластырылғанын көрсетеді.

Келесі сурет клиент (браузер) сұраған кезде қолданбаның не істейтінін көрсетеді /guestbookURL.

Linux желілік қолданбасының өнімділігі. Кіріспе
Қонақ кітапшасы қолданбасы қалай жұмыс істейді

Қонақ кітабының бетін шығару қажет болғанда, үлгіні жадқа оқу үшін файлдық жүйеге бір қоңырау және Redis-ке үш желілік қоңырау болады. Үлгі файлы жоғарыдағы скриншоттағы бетке арналған HTML мазмұнының көпшілігін қамтиды. Сондай-ақ мазмұнның динамикалық бөлігі үшін арнайы толтырғыштар бар: хабарламалар және келушілер есептегіші. Біз оларды Redis-тен аламыз, оларды бетке енгіземіз және клиентке толық қалыптасқан мазмұнды береміз. Redis-ке үшінші қоңырауды болдырмауға болады, себебі Redis ұлғайған кезде жаңа кілт мәнін қайтарады. Дегенмен, оқиғаларға негізделген асинхронды архитектурасы бар серверіміз үшін көптеген желілік қоңыраулар оқу мақсаттары үшін жақсы сынақ болып табылады. Сондықтан біз келушілер санының Redis қайтару мәнін алып тастаймыз және оны бөлек қоңырау арқылы сұраймыз.

Сервер архитектурасы ZeroHTTPd

Біз бірдей функционалдық, бірақ архитектурасы әртүрлі ZeroHTTPd жеті нұсқасын жасап жатырмыз:

  • Итеративті
  • Fork сервер (әр сұрау үшін бір еншілес процесс)
  • Пре-форк сервері (процестерді алдын ала айыру)
  • Орындау ағындары бар сервер (әр сұрау үшін бір ағын)
  • Алдын ала ағынды жасаумен сервер
  • Архитектураға негізделген poll()
  • Архитектураға негізделген epoll

Біз серверді HTTP сұрауларымен жүктеу арқылы әрбір архитектураның өнімділігін өлшейміз. Бірақ жоғары параллельді архитектураларды салыстырған кезде сұраулар саны артады. Үш рет сынақтан өткізіп, орташа мәнді есептейміз.

Тестілеу әдістемесі

Linux желілік қолданбасының өнімділігі. Кіріспе
ZeroHTTPd жүктеме сынағы орнату

Сынақтарды орындау кезінде барлық компоненттер бір құрылғыда жұмыс істемеуі маңызды. Бұл жағдайда құрамдас бөліктер CPU үшін бәсекелесетіндіктен, ОЖ қосымша жоспарлау шығындарын алады. Таңдалған сервер архитектураларының әрқайсысының операциялық жүйенің үстеме шығынын өлшеу осы жаттығудың ең маңызды мақсаттарының бірі болып табылады. Көбірек айнымалыларды қосу процеске зиянды болады. Сондықтан жоғарыдағы суреттегі параметр жақсы жұмыс істейді.

Бұл серверлердің әрқайсысы не істейді?

  • load.unixism.net: Бұл жерде біз жүгіреміз ab, Apache Benchmark утилитасы. Ол сервер архитектураларын тексеру үшін қажетті жүктемені жасайды.
  • nginx.unixism.net: Кейде біз серверлік бағдарламаның бірнеше данасын іске қосқымыз келеді. Мұны істеу үшін сәйкес параметрлері бар Nginx сервері келетін жүктеме теңестіруші ретінде жұмыс істейді ab серверлік процестерімізге.
  • zerohttpd.unixism.net: Мұнда біз серверлік бағдарламаларды бір уақытта жеті түрлі архитектурада іске қосамыз.
  • redis.unixism.net: Бұл сервер Redis демонын іске қосады, мұнда қонақтар кітабының жазбалары мен келушілер есептегіштері сақталады.

Барлық серверлер бір процессор өзегінде жұмыс істейді. Идея - әрбір архитектураның максималды өнімділігін бағалау. Барлық серверлік бағдарламалар бір аппараттық құралда сыналғандықтан, бұл салыстыру үшін негіз болып табылады. Менің сынақ орнатуым Digital Ocean компаниясынан жалға алынған виртуалды серверлерден тұрады.

Біз нені өлшеп жатырмыз?

Сіз әртүрлі көрсеткіштерді өлшей аласыз. Параллельдіктің әртүрлі деңгейлеріндегі сұраулары бар серверлерді жүктеу арқылы берілген конфигурациядағы әрбір архитектураның өнімділігін бағалаймыз: жүктеме бір мезгілде 20-дан 15 000 пайдаланушыға дейін өседі.

Тест нәтижелері

Келесі диаграмма параллелизмнің әртүрлі деңгейлеріндегі әртүрлі архитектуралардағы серверлердің өнімділігін көрсетеді. Y осі – секундына сұраныс саны, х осі – параллель қосылымдар.

Linux желілік қолданбасының өнімділігі. Кіріспе

Linux желілік қолданбасының өнімділігі. Кіріспе

Linux желілік қолданбасының өнімділігі. Кіріспе

Төменде нәтижелер бар кесте берілген.

секундына сұраныс

келісу
қайталанатын
шанышқы
алдын ала шанышқы
ағын
алдын ала ағын
сауалнама
эполл

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-нан астам бір уақыттағы сұраулардан бізде тек екі ойыншы қалғанын көруге болады: pre-fork және epoll. Жүктеме ұлғайған сайын сауалнамаға негізделген сервер ағынды серверге қарағанда нашар жұмыс істейді. Жіпті алдын ала жасау архитектурасы epoll үшін лайықты бәсекелес болып табылады, бұл Linux ядросының ағындардың көп санын қаншалықты жақсы жоспарлайтынының куәсі.

ZeroHTTPd бастапқы коды

ZeroHTTPd бастапқы коды осында. Әрбір архитектура үшін жеке каталог бар.

ZeroHTTPd │ ├── 01_итеративті │ ├── main.c ├── 02_forking │ ├── main.c ├── 03_preforking негізгі ──c.──c. 04_ бұрау │ ├── main.c ├── 05_prethreading │ ├── main.c ├── 06_poll │ ├── main.c ├── 07_epoll │ └── main.c │ └── main.c ── жалпыға ортақ ─── ├── индекс .html │ └── tux png └── үлгілері └── қонақ кітабы └── index.html

Барлық архитектураға арналған жеті каталогтан басқа, жоғарғы деңгейлі каталогта тағы екеуі бар: жалпы және үлгілер. Біріншісі index.html файлын және бірінші скриншоттағы кескінді қамтиды. Онда басқа файлдар мен қалталарды қоюға болады және ZeroHTTPd бұл статикалық файлдарға еш қиындықсыз қызмет етуі керек. Браузердегі жол жалпы қалтадағы жолға сәйкес келсе, ZeroHTTPd осы каталогтан index.html файлын іздейді. Қонақ кітабының мазмұны динамикалық түрде жасалады. Оның тек басты беті бар және оның мазмұны "templates/guestbook/index.html" файлына негізделген. ZeroHTTPd кеңейтім үшін динамикалық беттерді оңай қосады. Идея мынада: пайдаланушылар осы каталогқа үлгілерді қосып, қажет болған жағдайда ZeroHTTPd кеңейте алады.

Барлық жеті серверді құру үшін іске қосыңыз make all жоғарғы деңгейлі каталогтан - және барлық құрастырулар осы каталогта пайда болады. Орындалатын файлдар олар іске қосылған каталогтан жалпы және үлгі каталогтарын іздейді.

Linux API

Осы мақалалар сериясындағы ақпаратты түсіну үшін сізге Linux API интерфейсін жақсы білу қажет емес. Дегенмен, мен осы тақырып бойынша көбірек оқуды ұсынамын, Интернетте көптеген анықтамалық ресурстар бар. Біз Linux API интерфейстерінің бірнеше санаттарына тоқталсақ та, біздің назарымыз негізінен процестерге, ағындарға, оқиғаларға және желілік стектерге бөлінеді. Linux API туралы кітаптар мен мақалалардан басқа, жүйелік қоңыраулар мен пайдаланылған кітапхана функциялары үшін мананы оқуды ұсынамын.

Өнімділік және масштабтау

Өнімділік пен ауқымдылық туралы бір ескертпе. Теориялық тұрғыдан олардың арасында ешқандай байланыс жоқ. Сізде өте жақсы жұмыс істейтін, жауап беру уақыты бірнеше миллисекунд болатын веб-қызмет болуы мүмкін, бірақ ол мүлдем масштабталмайды. Сол сияқты, жауап беру үшін бірнеше секунд кететін нашар жұмыс істейтін веб-бағдарлама болуы мүмкін, бірақ ол бір мезгілде он мыңдаған пайдаланушыларды өңдеу үшін ондағанға дейін ұлғаяды. Дегенмен, жоғары өнімділік пен ауқымдылықтың тіркесімі өте қуатты комбинация болып табылады. Жоғары өнімді қолданбалар әдетте ресурстарды үнемді пайдаланады және осылайша серверде бір мезгілде көбірек пайдаланушыларға тиімді қызмет етеді, бұл шығындарды азайтады.

CPU және енгізу/шығару тапсырмалары

Ақырында, есептеулерде әрқашан екі ықтимал тапсырма түрі бар: енгізу/шығару және процессор үшін. Интернет арқылы сұрауларды қабылдау (желілік енгізу-шығару), файлдарға қызмет көрсету (желі және дискідегі енгізу-шығару), деректер қорымен байланысу (желі және дискідегі енгізу-шығару) - барлығы енгізу/шығару әрекеттері. Кейбір дерекқор сұраулары процессорды аздап қажет етуі мүмкін (сұрыптау, орташа миллион нәтиже және т.б.). Көптеген веб-қосымшалар максималды ықтимал енгізу/шығарумен шектеледі, ал процессор толық қуатта сирек пайдаланылады. Кейбір енгізу/шығару тапсырмалары процессорды көп пайдаланып жатқанын көргенде, бұл, ең алдымен, нашар қолданба архитектурасының белгісі. Бұл процессорлық ресурстар процесті басқаруға және контекстті ауыстыруға жұмсалатынын білдіруі мүмкін - бұл мүлдем пайдалы емес. Егер сіз кескінді өңдеу, аудио файлды түрлендіру немесе машинада оқыту сияқты бірдеңе жасап жатсаңыз, қолданба қуатты CPU ресурстарын қажет етеді. Бірақ көптеген қолданбалар үшін бұлай емес.

Сервер архитектуралары туралы көбірек біліңіз

  1. I бөлім: Итеративті архитектура
  2. II бөлім. Шанышқы серверлері
  3. III бөлім. Алдын ала айыру серверлері
  4. IV бөлім. Орындау ағындары бар серверлер
  5. V бөлім. Алдын ала ағынды серверлер
  6. VI бөлім. Пол негізіндегі архитектура
  7. VII бөлім. epoll негізіндегі архитектура

Ақпарат көзі: www.habr.com

пікір қалдыру