Веб-тиркемелер азыр бардык жерде колдонулат жана бардык транспорттук протоколдордун арасында HTTP негизги үлүшүн ээлейт. Веб тиркемелерди иштеп чыгуунун нюанстарын изилдеп жатканда, көпчүлүк адамдар бул тиркемелер чындап иштеген операциялык системага өтө аз көңүл бурушат. Өнүгүү (Dev) менен операциялардын (Ops) бөлүнүшү кырдаалды ого бетер начарлатты. Бирок DevOps маданиятынын өсүшү менен, иштеп чыгуучулар өздөрүнүн тиркемелерин булутта иштетүү үчүн жоопкерчиликтүү болуп калышты, андыктан операциялык тутумдун бэкэнди менен жакшылап таанышуу алар үчүн абдан пайдалуу. Бул, өзгөчө, сиз миңдеген же он миңдеген бир эле учурда туташуулар үчүн системаны жайылтууга аракет кылып жатсаңыз, пайдалуу.
Веб кызматтарындагы чектөөлөр башка колдонмолордогу чектөөлөргө абдан окшош. Бул жүк баланстоочу же маалымат базасынын серверлери болобу, бул колдонмолордун бардыгында жогорку өндүрүмдүүлүктөгү чөйрөдө окшош көйгөйлөр бар. Бул негизги чектөөлөрдү түшүнүү жана аларды жалпысынан кантип жеңүү сизге веб-тиркемелериңиздин натыйжалуулугун жана масштабдуулугун баалоого жардам берет.
Мен бул макалалар сериясын жакшы маалымдалган система архитектору болгусу келген жаш иштеп чыгуучулардын суроолоруна жооп катары жазып жатам. Linux тиркемелерин оптималдаштыруу ыкмаларын, алардын иштөө тутумунун деңгээлинде кандай иштээрин түшүнбөстөн так түшүнүү мүмкүн эмес. Тиркемелердин көптөгөн түрлөрү бар болсо да, бул серияда мен браузер же текст редактору сыяктуу рабочий тиркемелерди эмес, веб-негизделген тиркемелерди изилдегим келет. Бул материал Linux же Unix программалары кандай иштээрин жана аларды жогорку аткаруу үчүн кантип түзүүнү түшүнгүсү келген иштеп чыгуучулар жана архитекторлор үчүн арналган.
Linux болуп саналат сервер бөлмөсү операциялык системасы жана көбүнчө сиздин тиркемелериңиз ушул ОСте иштейт. Мен "Linux" деп айтсам да, сиз көбүнчө Unix сыяктуу операциялык системалардын бардыгын айтып жатам деп ишенсеңиз болот. Бирок, мен башка системаларда коштоочу кодду сынай элекмин. Демек, сизди FreeBSD же OpenBSD кызыктырса, натыйжа башкача болушу мүмкүн. Мен Linux үчүн кандайдыр бир нерсени сынап көргөндө, мен аны көрсөтөм.
Бул билимди нөлдөн баштап тиркемени куруу үчүн колдонсоңуз болот жана ал эң сонун оптималдаштырылат, бирок муну кылбаганыңыз жакшы. Эгер сиз уюмуңуздун бизнес тиркемеси үчүн C же C++ тилдеринде жаңы веб-сервер жазсаңыз, бул жумуштагы акыркы күнүңүз болушу мүмкүн. Бирок, бул колдонмолордун структурасын билүү учурдагы программаларды тандоого жардам берет. Сиз процесске негизделген системаларды жипке негизделген системалар менен, ошондой эле окуяга негизделген системаларды салыштыра аласыз. Сиз эмне үчүн Nginx Apache httpd караганда жакшыраак иштей турганын, эмне үчүн Tornado негизиндеги Python тиркемеси Django негизиндеги Python тиркемелерине салыштырмалуу көбүрөөк колдонуучуларга кызмат кыла аларын түшүнөсүз жана баалайсыз.
ZeroHTTPd: Окуу куралы
бул мен окутуу куралы катары C тилинде нөлдөн баштап жазган веб-сервер. Анын эч кандай тышкы көз карандылыгы жок, анын ичинде Redisге кирүү мүмкүнчүлүгү. Биз өзүбүздүн Redis процедураларыбызды иштетебиз. Көбүрөөк маалымат алуу үчүн төмөндө караңыз.
Теорияны кенен талкуулай алсак да, код жазуудан, аны иштетүүдөн жана сервердин бардык архитектураларын бири-бири менен салыштыруудан артык эч нерсе жок. Бул эң айкын ыкма. Ошондуктан, биз ар бир моделди колдонуу менен жөнөкөй ZeroHTTPd веб серверин жазабыз: процесске негизделген, жипке негизделген жана окуяга негизделген. Келгиле, бул серверлердин ар бирин карап көрөлү жана алардын бири-бирине салыштырмалуу кандай иштегенин көрөлү. ZeroHTTPd бир C файлында ишке ашырылган окуяга негизделген сервер , бир баш файлда келген улуу хэш таблицасын ишке ашыруу. Башка учурларда, долбоорду татаалдаштырбоо үчүн, эч кандай көз карандылык жок.
Коддо түшүнүүгө жардам бере турган көптөгөн комментарийлер бар. Коддун бир нече саптарынан турган жөнөкөй веб-сервер болгондуктан, ZeroHTTPd веб-иштеп чыгуу үчүн минималдуу алкак болуп саналат. Ал чектелген функцияга ээ, бирок статикалык файлдарды жана өтө жөнөкөй "динамикалык" баракчаларды тейлөөгө жөндөмдүү. Мен ZeroHTTPd жогорку натыйжалуу Linux тиркемелерин түзүүнү үйрөнүү үчүн жакшы экенин айтышым керек. Жалпысынан алганда, көпчүлүк веб-кызматтар суроо-талаптарды күтүп, аларды текшерип, иштетишет. ZeroHTTPd дал ушундай кылат. Бул өндүрүш эмес, окуу куралы. Бул каталарды башкарууда жакшы эмес жана коопсуздуктун мыкты тажрыйбалары менен мактана албайт (ооба, мен колдонгонмун) strcpy) же Си тилинин акылдуу амалдары, бирок мен ал өз милдетин жакшы аткарат деп үмүттөнөм.
ZeroHTTPd башкы бети. Ал ар кандай файл түрлөрүн, анын ичинде сүрөттөрдү чыгара алат
Конок китебинин арызы
Заманбап веб-тиркемелер адатта статикалык файлдар менен чектелбейт. Алар ар кандай маалымат базалары, кэштер жана башкалар менен татаал өз ара аракеттенишүүдө. Ошентип, биз "Конок китеби" деп аталган жөнөкөй веб тиркемени түзөбүз, анда коноктор өз ысымдары менен жазууларды калтырышат. Коноктор китеби дүкөндөрүнүн жазуулары мурда калган. Барактын ылдый жагында коноктор үчүн эсептегич да бар.
Веб тиркеме "Конок китеби" ZeroHTTPd
Коноктордун эсептегичтери жана коноктор китебинин жазуулары Редисте сакталат. Redis менен байланышуу үчүн, алар тышкы китепканадан көз каранды эмес, өз процедуралары ишке ашырылат; Мен жалпыга жеткиликтүү жана жакшы сыналган чечимдер болгондо homebrew кодун чыгаруунун чоң күйөрманы эмесмин. Бирок ZeroHTTPd максаты Linux иштешин жана тышкы кызматтарга кирүү мүмкүнчүлүгүн изилдөө, ал эми HTTP суроо-талаптарын тейлөө аткарууга олуттуу таасирин тийгизет. Ар бир сервер архитектурасында Redis менен байланышты толугу менен көзөмөлдөшүбүз керек. Кээ бир архитектураларда биз чалууларды бөгөттөп, башкаларында окуяга негизделген процедураларды колдонобуз. Тышкы Redis кардар китепканасын колдонуу бул башкарууну камсыз кылбайт. Андан тышкары, биздин кичинекей Redis кардары бир нече функцияларды гана аткарат (ачкычты алуу, орнотуу жана көбөйтүү; массивди алуу жана ага кошуу). Мындан тышкары, Redis протоколу абдан жарашыктуу жана жөнөкөй. Аны атайын үйрөтүүнүн деле кереги жок. Протоколдун бардык иштерди жүзгө жакын код саптарында аткарганынын өзү эле анын канчалык жакшы ойлонулганын көрсөтүп турат.
Төмөнкү сүрөт кардар (браузер) сураганда, колдонмо эмне кылаарын көрсөтөт /guestbookURL.
Конок китеби колдонмосу кантип иштейт
Конок китеби барагын чыгаруу керек болгондо, шаблонду эс тутумга окуу үчүн файл тутумуна бир чалуу жана Redisге үч тармактык чалуу болот. Үлгү файлы жогорудагы скриншоттогу барактын HTML мазмунунун көбүн камтыйт. Ошондой эле мазмундун динамикалык бөлүгү үчүн атайын толтургучтар бар: билдирүүлөр жана коноктор эсептегич. Биз аларды Redisден алып, баракчага киргизип, кардарга толук калыптанган мазмунду беребиз. Redisге үчүнчү чалуудан качууга болот, анткени Redis көбөйгөндө жаңы ачкыч маанисин кайтарат. Бирок, окуяга негизделген асинхрондук архитектурасы бар серверибиз үчүн көптөгөн тармактык чалуулар окуу максатында жакшы сыноо болуп саналат. Ошентип, биз зыяратчылардын саны жөнүндө Redis кайтаруу маанисин жокко чыгарабыз жана аны өзүнчө чалуу менен сурайбыз.
Сервер архитектуралары ZeroHTTPd
Биз ZeroHTTPdнин жети версиясын түзүп жатабыз, функциялары бирдей, бирок архитектурасы ар башка:
- Итеративдик
- Fork сервери (ар бир суроо үчүн бир бала процесси)
- Алдын ала айры сервер (процесстерди алдын ала форкациялоо)
- Аткаруу жиптери бар сервер (ар бир суроо үчүн бир жип)
- Алдын ала жипти түзүү менен сервер
- Архитектура негизделген
poll() - Архитектура негизделген
epoll
Ар бир архитектуранын өндүрүмдүүлүгүн серверге HTTP сурамдары менен жүктөө менен өлчөйбүз. Бирок өтө параллелдүү архитектураларды салыштырганда, сурамдардын саны көбөйөт. Үч жолу текшерип, орточо эсепти эсептейбиз.
Сыноо методологиясы
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 огу - секундасына суроо-талаптардын саны, x огу - параллелдүү байланыштар.
Төмөндө натыйжалары менен таблица болуп саналат.
секундасына суроо-талаптар
параллелизм
кайталануучу
айры
алдын ала айры
агым
алдын ала агым
добуш
epoll
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 Source Code
ZeroHTTPd Source Code . Ар бир архитектура үчүн өзүнчө каталог бар.
ZeroHTTPd │ ├── 01_итеративдик │ ├── main.c ├── 02_forking │ ├── main.c ├── 03_preforking ─c.──04 _th окуу │ ├── 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 жана киргизүү/чыгаруу милдеттери
Акырында, эсептөөдө ар дайым эки мүмкүн болгон тапшырмалар бар: I/O жана CPU үчүн. Интернет аркылуу суроо-талаптарды кабыл алуу (тармактык киргизүү/чыгаруу), файлдарды тейлөө (тармак жана дискти киргизүү/чыгаруу), маалымат базасы менен байланышуу (тармак жана дискти киргизүү/чыгаруу) бардык киргизүү/чыгаруу иш-аракеттери болуп саналат. Кээ бир маалымат базасы сурамдары бир аз CPU интенсивдүү болушу мүмкүн (сорттоо, орточо миллион натыйжа ж.б.). Көпчүлүк веб-тиркемелер максималдуу мүмкүн болгон киргизүү/чыгаруу менен чектелген жана процессор толук кубаттуулукта сейрек колдонулат. Кээ бир I/O тапшырмасы көп CPU колдонуп жатканын көргөндө, бул, кыязы, начар колдонмо архитектурасынын белгиси. Бул процессти башкарууга жана контекстти алмаштырууга CPU ресурстары текке кетип жатканын билдириши мүмкүн - бул толугу менен пайдалуу эмес. Эгер сиз сүрөт иштетүү, аудио файлды конверсиялоо же машина үйрөнүү сыяктуу бир нерсе кылып жатсаңыз, анда колдонмо күчтүү CPU ресурстарын талап кылат. Бирок көпчүлүк колдонмолор үчүн бул андай эмес.
Сервер архитектуралары жөнүндө көбүрөөк билүү
Source: www.habr.com