Vefforrit eru nú notuð alls staðar og meðal allra flutningssamskiptareglna er HTTP bróðurpartinn. Þegar þeir rannsaka blæbrigði vefforritaþróunar, taka flestir mjög litla athygli á stýrikerfinu þar sem þessi forrit keyra í raun og veru. Aðskilnaður þróunar (Dev) og rekstrar (Ops) gerði ástandið aðeins verra. En með uppgangi DevOps menningarinnar eru þróunaraðilar að verða ábyrgir fyrir því að keyra forritin sín í skýinu, svo það er mjög gagnlegt fyrir þá að kynnast vel bakenda stýrikerfisins. Þetta er sérstaklega gagnlegt ef þú ert að reyna að dreifa kerfi fyrir þúsundir eða tugþúsundir samtímis tenginga.
Takmarkanir í vefþjónustu eru mjög svipaðar og í öðrum forritum. Hvort sem það eru álagsjafnarar eða gagnagrunnsþjónar, þá eiga öll þessi forrit við svipuð vandamál í afkastamiklu umhverfi. Að skilja þessar grundvallartakmarkanir og hvernig á að sigrast á þeim almennt mun hjálpa þér að meta árangur og sveigjanleika vefforritanna þinna.
Ég er að skrifa þessa greinaröð sem svar við spurningum ungra hönnuða sem vilja verða vel upplýstir kerfisarkitektar. Það er ómögulegt að skilja hagræðingartækni Linux forrita með skýrum hætti án þess að kafa ofan í grunnatriðin í því hvernig þau virka á stýrikerfisstigi. Þó að það séu margar gerðir af forritum, vil ég í þessari röð kanna netforrit frekar en skrifborðsforrit eins og vafra eða textaritli. Þetta efni er ætlað forriturum og arkitektum sem vilja skilja hvernig Linux eða Unix forrit virka og hvernig á að byggja þau upp fyrir mikla afköst.
Linux er netþjónaherbergi stýrikerfi, og oftast keyra forritin þín á þessu stýrikerfi. Þó ég segi „Linux“, þá er oftast óhætt að gera ráð fyrir að ég eigi við öll Unix-lík stýrikerfi almennt. Hins vegar hef ég ekki prófað meðfylgjandi kóða á öðrum kerfum. Svo, ef þú hefur áhuga á FreeBSD eða OpenBSD, gætu niðurstöður þínar verið mismunandi. Þegar ég reyni eitthvað Linux-sérstakt, bendi ég á það.
Þó að þú getir notað þessa þekkingu til að byggja upp app frá grunni og það verður fullkomlega fínstillt, þá er best að gera það ekki. Ef þú skrifar nýjan vefþjón í C eða C++ fyrir viðskiptaforrit fyrirtækisins þíns gæti þetta verið síðasti vinnudagurinn þinn. Hins vegar að þekkja uppbyggingu þessara forrita mun hjálpa til við að velja núverandi forrit. Þú munt geta borið saman ferlitengd kerfi við þráðbundin kerfi sem og atburðabyggð. Þú munt skilja og meta hvers vegna Nginx gengur betur en Apache httpd, hvers vegna Tornado byggt Python forrit getur þjónað fleiri notendum samanborið við Django byggt Python forrit.
ZeroHTTPd: Námstæki
er vefþjónn sem ég skrifaði frá grunni í C sem kennslutæki. Það hefur engin ytri ósjálfstæði, þar á meðal aðgang að Redis. Við rekum okkar eigin Redis verklag. Sjá nánar fyrir neðan.
Þó að við gætum rætt kenningarnar í löngu máli, þá er ekkert betra en að skrifa kóða, keyra hann og bera saman alla netþjónaarkitektúr sín á milli. Þetta er augljósasta aðferðin. Þess vegna munum við skrifa einfaldan ZeroHTTPd vefþjón með því að nota hvert líkan: ferli byggt, þráð byggt og atburða byggt. Við skulum skoða hvern þessara netþjóna og sjá hvernig þeir standa sig samanborið við hvern annan. ZeroHTTPd er útfært í einni C skrá. Atburðamiðlarinn inniheldur , frábær útfærsla á kjötkássatöflu sem kemur í einni hausskrá. Í öðrum tilfellum eru engar ósjálfstæðir, til að flækja ekki verkefnið.
Það eru fullt af athugasemdum í kóðanum til að hjálpa þér að skilja. Þar sem ZeroHTTPd er einfaldur vefþjónn í nokkrum línum af kóða, er ZeroHTTPd líka lágmarksramma fyrir vefþróun. Það hefur takmarkaða virkni, en er fær um að þjóna kyrrstæðum skrám og mjög einföldum „dýnamískum“ síðum. Ég verð að segja að ZeroHTTPd er gott til að læra hvernig á að búa til afkastamikil Linux forrit. Í stórum dráttum bíða flestar vefþjónustur eftir beiðnum, athuga þær og vinna úr þeim. Þetta er nákvæmlega það sem ZeroHTTPd mun gera. Þetta er tæki til að læra, ekki framleiðslu. Það er ekki frábært í villumeðferð og er ólíklegt að hann státi af bestu öryggisaðferðum (ó já, ég notaði strcpy) eða snjöllum brögðum C-málsins. En ég vona að það skili sínu starfi vel.
ZeroHTTPd heimasíða. Það getur gefið út mismunandi skráargerðir þar á meðal myndir
Umsókn um gestabók
Nútíma vefforrit eru venjulega ekki takmörkuð við kyrrstæðar skrár. Þeir hafa flókin samskipti við ýmsa gagnagrunna, skyndiminni osfrv. Þannig að við munum búa til einfalt vefforrit sem kallast „Gestabók“ þar sem gestir skilja eftir færslur undir nafni sínu. Gestabókin geymir færslur fyrr. Það er líka gestateljari neðst á síðunni.
Vefforritið „Gestabók“ ZeroHTTPd
Gestateljari og gestabókarfærslur eru geymdar í Redis. Fyrir samskipti við Redis eru eigin verklagsreglur innleiddar, þær eru ekki háðar ytra bókasafni. Ég er ekki mikill aðdáandi þess að setja út heimabruggkóða þegar það eru til opinberar og vel prófaðar lausnir. En tilgangurinn með ZeroHTTPd er að rannsaka afköst Linux og aðgang að ytri þjónustu, á meðan að þjóna HTTP beiðnum hefur alvarleg áhrif á frammistöðu. Við verðum að hafa fulla stjórn á samskiptum við Redis í hverri netþjónaarkitektúr okkar. Í sumum arkitektúrum notum við lokunarsímtöl, í öðrum notum við atburðabundnar aðferðir. Notkun utanaðkomandi Redis biðlarasafns mun ekki veita þessa stjórn. Að auki framkvæmir litli Redis viðskiptavinurinn okkar aðeins nokkrar aðgerðir (fá, stilla og hækka lykil; fá og bæta við fylki). Að auki er Redis samskiptareglan einstaklega glæsileg og einföld. Þú þarft ekki einu sinni að kenna það sérstaklega. Sú staðreynd að samskiptareglan vinnur alla vinnu í um hundrað línum af kóða sýnir hversu vel ígrunduð hún er.
Eftirfarandi mynd sýnir hvað forritið gerir þegar biðlarinn (vafri) biður um /guestbookURL.
Hvernig gestabókarumsóknin virkar
Þegar gefa þarf út gestabókarsíðu er eitt símtal í skráarkerfið til að lesa sniðmátið inn í minni og þrjú netsímtöl til Redis. Sniðmátsskráin inniheldur mest af HTML innihaldi síðunnar á skjámyndinni hér að ofan. Það eru líka sérstakir staðgenglar fyrir kraftmikla hluta efnisins: færslur og gestateljari. Við tökum á móti þeim frá Redis, setjum þau inn á síðuna og veitum viðskiptavininum fullmótað efni. Hægt er að forðast þriðja símtalið til Redis vegna þess að Redis skilar nýja lykilgildinu þegar það er aukið. Hins vegar, fyrir netþjóninn okkar, sem er með ósamstilltan atburðabyggðan arkitektúr, eru mörg netsímtöl góð próf í námstilgangi. Þannig að við fleygum Redis skilagildinu fyrir fjölda gesta og spyrjum um það með sérstöku símtali.
Server arkitektúr ZeroHTTPd
Við erum að byggja sjö útgáfur af ZeroHTTPd með sömu virkni en mismunandi arkitektúr:
- Ítrekun
- Fork server (eitt barn ferli á beiðni)
- Forgafflaþjónn (forgafflun ferla)
- Server með framkvæmdarþræði (einn þráður á beiðni)
- Server með forþráðagerð
- Byggt á arkitektúr
poll() - Byggt á arkitektúr
epoll
Við mælum frammistöðu hvers arkitektúrs með því að hlaða þjóninum með HTTP beiðnum. En þegar borinn er saman mjög samhliða arkitektúr eykst fjöldi fyrirspurna. Við prófum þrisvar sinnum og reiknum meðaltalið.
Prófunaraðferðafræði
ZeroHTTPd hleðsluprófunaruppsetning
Mikilvægt er að þegar prófanir eru keyrðar gangi ekki allir íhlutir á sömu vélina. Í þessu tilviki fylgir stýrikerfinu viðbótarkostnaði við tímasetningu þar sem íhlutir keppa um CPU. Mæling á stýrikerfiskostnaði hvers af völdum netþjónaarkitektúrum er eitt mikilvægasta markmið þessarar æfingar. Að bæta við fleiri breytum mun verða skaðlegt ferlinu. Þess vegna virkar stillingin á myndinni hér að ofan best.
Hvað gerir hver þessara netþjóna?
- load.unixism.net: Þetta er þar sem við keyrum
ab, Apache Benchmark gagnsemi. Það býr til álagið sem þarf til að prófa netþjónaarkitektúr okkar. - nginx.unixism.net: Stundum viljum við keyra fleiri en eitt tilvik af netþjónsforriti. Til að gera þetta virkar Nginx þjónninn með viðeigandi stillingum sem álagsjafnari sem kemur frá ab til netþjónaferla okkar.
- zerohttpd.unixism.net: Hér keyrum við netþjónaforritin okkar á sjö mismunandi arkitektúrum, einum í einu.
- redis.unixism.net: Þessi þjónn keyrir Redis púkann, þar sem gestabókarfærslur og gestateljarar eru geymdar.
Allir netþjónar keyra á sama örgjörvakjarna. Hugmyndin er að meta hámarksafköst hvers arkitektúrs. Þar sem öll netþjónaforrit eru prófuð á sama vélbúnaði er þetta grunnlína til samanburðar. Prófunaruppsetningin mín samanstendur af sýndarþjónum sem eru leigðir frá Digital Ocean.
Hvað erum við að mæla?
Þú getur mælt mismunandi vísbendingar. Við metum frammistöðu hvers arkitektúrs í tiltekinni uppsetningu með því að hlaða á netþjóna með beiðnum á mismunandi stigum samhliða: álagið vex úr 20 í 15 samhliða notendur.
Niðurstöður prófana
Eftirfarandi mynd sýnir frammistöðu netþjóna á mismunandi arkitektúr á mismunandi stigum samhliða. Y-ásinn er fjöldi beiðna á sekúndu, x-ásinn er samhliða tengingar.
Hér að neðan er tafla með niðurstöðum.
beiðnir á sekúndu
samhliða
endurtekið
gaffal
forgaffli
streymi
forstreymi
inn
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
stór útbreiðslu
2138
5000
-
stór útbreiðslu
1600
1100
2519
-
2235
8000
-
-
1200
stór útbreiðslu
2451
-
2100
10 000
-
-
stór útbreiðslu
-
2200
-
2200
11 000
-
-
-
-
2200
-
2122
12 000
-
-
-
-
970
-
1958
13 000
-
-
-
-
730
-
1897
14 000
-
-
-
-
590
-
1466
15 000
-
-
-
-
532
-
1281
Af línuritinu og töflunni má sjá að fyrir ofan 8000 samtímis beiðnir eigum við aðeins tvo leikmenn eftir: pre-fork og epoll. Eftir því sem álagið eykst skilar netþjónn sem byggir á skoðanakönnunum verri árangur en streymandi. Þráða-for-sköpunararkitektúrinn er verðugur keppinautur epoll, sem er vitnisburður um hversu vel Linux kjarninn skipuleggur mikinn fjölda þráða.
ZeroHTTPd frumkóði
ZeroHTTPd frumkóði . Það er sérstök skrá fyrir hvern arkitektúr.
ZeroHTTPd │ ├── 01_iterative │ ├── main.c ├── 02_forking │ ├── main.c ├── 03_preforking ───├ │ _ þráður │ ├── aðal.c ├── 04_forþráður │ ├── main.c ├── 05_poll │ ├── main.c ├── 06_epoll │ └─── main.c ├ ├── index .html │ └── tux . png └── sniðmát └── gestabók └── index.html
Til viðbótar við sjö möppur fyrir alla arkitektúra eru tvær í viðbót í efstu möppunni: opinber og sniðmát. Sú fyrsta inniheldur index.html skrána og myndina frá fyrstu skjámyndinni. Þú getur sett aðrar skrár og möppur þar og ZeroHTTPd ætti að þjóna þeim kyrrstæðum skrám án vandræða. Ef slóðin í vafranum passar við slóðina í almennu möppunni, þá leitar ZeroHTTPd að index.html skránni í þessari möppu. Innihald gestabókarinnar er myndað á kraftmikinn hátt. Það hefur aðeins heimasíðu og innihald hennar er byggt á skránni 'templates/guestbook/index.html'. ZeroHTTPd bætir auðveldlega við kraftmiklum síðum til framlengingar. Hugmyndin er sú að notendur geti bætt sniðmátum við þessa möppu og framlengt ZeroHTTPd eftir þörfum.
Til að byggja alla sjö netþjónana skaltu keyra make all úr möppunni á efstu stigi - og allar byggingar birtast í þessari möppu. Keyranlegar skrár leita að almennum og sniðmátsmöppum í möppunni sem þær eru ræstar úr.
Linux API
Þú þarft ekki að vera vel að sér í Linux API til að skilja upplýsingarnar í þessari greinaröð. Hins vegar mæli ég með því að þú lesir meira um þetta efni; það eru margar tilvísanir á netinu. Þrátt fyrir að við munum snerta nokkra flokka Linux API, mun áherslan okkar fyrst og fremst vera á ferlum, þræði, atburðum og netstaflanum. Til viðbótar við bækur og greinar um Linux API mæli ég líka með því að lesa mana fyrir kerfissímtöl og bókasafnsaðgerðir sem notaðar eru.
Afköst og sveigjanleiki
Ein athugasemd um frammistöðu og sveigjanleika. Fræðilega séð eru engin tengsl þar á milli. Þú getur verið með vefþjónustu sem virkar mjög vel, með viðbragðstíma upp á nokkrar millisekúndur, en hún mælist alls ekki. Sömuleiðis getur verið vefforrit sem skilar illa árangri sem tekur nokkrar sekúndur að svara, en það stækkar um tugi til að meðhöndla tugþúsundir samhliða notenda. Hins vegar er samsetningin af mikilli afköstum og sveigjanleika mjög öflug samsetning. Afkastamikil forrit nota almennt auðlindir sparlega og þjóna þannig á skilvirkan hátt fleiri samhliða notendum á þjóninum, sem dregur úr kostnaði.
CPU og I/O verkefni
Að lokum, í tölvumálum eru alltaf tvær mögulegar gerðir verkefna: fyrir I/O og CPU. Að taka á móti beiðnum í gegnum internetið (net I/O), þjónusta skrár (net og diskur I/O), samskipti við gagnagrunninn (net og diskur I/O) eru allt I/O starfsemi. Sumar gagnagrunnsfyrirspurnir geta verið svolítið örgjörvafrekar (flokkun, að meðaltali milljón niðurstöður osfrv.). Flest vefforrit eru takmörkuð af hámarks mögulegu I/O og örgjörvinn er sjaldan notaður á fullri afköstum. Þegar þú sérð að eitthvað I/O verkefni notar mikinn örgjörva er það líklegast merki um lélegan forritaarkitektúr. Þetta getur þýtt að örgjörvaauðlindum sé sóað í ferlistjórnun og samhengisskipti - og þetta er ekki alveg gagnlegt. Ef þú ert að gera eitthvað eins og myndvinnslu, hljóðskráabreytingu eða vélanám, þá þarf forritið öflugt örgjörvaforða. En fyrir flest forrit er þetta ekki raunin.
Lærðu meira um netþjónaarkitektúr
Heimild: www.habr.com