Web aplikazioak gaur egun nonahi erabiltzen dira, eta garraio-protokolo guztien artean, HTTP-k hartzen du parte. Web aplikazioen garapenaren ñabardurak aztertzean, jende gehienak oso gutxi erreparatzen dio aplikazio hauek benetan exekutatzen diren sistema eragileari. Garapena (Dev) eta eragiketak (Ops) bereizteak egoera okerrera egin zuen. Baina DevOps kulturaren gorakadarekin, garatzaileak beren aplikazioak hodeian exekutatzeko ardura bihurtzen ari dira, beraz, oso erabilgarria da sistema eragilearen backend-a ondo ezagutzea. Hau bereziki erabilgarria da aldibereko milaka edo hamarnaka mila konexioetarako sistema bat zabaltzen saiatzen ari bazara.

Web zerbitzuen mugak beste aplikazioetakoen oso antzekoak dira. Karga-orekatzaileak edo datu-baseen zerbitzariak izan, aplikazio hauek guztiek antzeko arazoak dituzte errendimendu handiko ingurune batean. Oinarrizko muga hauek ulertzeak eta, oro har, nola gainditzeko zure web aplikazioen errendimendua eta eskalagarritasuna ebaluatzen lagunduko dizu.

Artikulu sorta hau idazten ari naiz sistema-arkitektu ongi informatuak izan nahi dituzten garatzaile gazteen galderei erantzunez. Ezinezkoa da Linux aplikazioen optimizazio teknikak argi ulertzea sistema eragilearen mailan funtzionatzen duten oinarrietan murgildu gabe. Aplikazio mota asko dauden arren, serie honetan web-oinarritutako aplikazioak arakatu nahi ditut mahaigaineko aplikazioak baino, arakatzailea edo testu editorea bezalakoak. Material hau Linux edo Unix programek nola funtzionatzen duten eta nola egituratu errendimendu handirako ulertu nahi duten garatzaile eta arkitektoentzat da.

Linux da zerbitzari gela sistema eragilea, eta gehienetan zure aplikazioak sistema eragile honetan exekutatzen dira. "Linux" esaten dudan arren, gehienetan seguru pentsa dezakezu Unix antzeko sistema eragile guztiak esan nahi dudala orokorrean. Hala ere, ez dut beste sistemetan batera doan kodea probatu. Beraz, FreeBSD edo OpenBSD interesatzen bazaizu, zure emaitzak alda daitezke. Linux-en berariazko zerbait probatzen dudanean, seinalatu egiten dut.

Ezagutza hori aplikazio bat hutsetik eraikitzeko erabil dezakezu eta ezin hobeto optimizatuta egongo den arren, hobe da hori ez egitea. Zure erakundearen negozio-aplikaziorako web zerbitzari berri bat C edo C++-n idazten baduzu, hau izan daiteke laneko azken eguna. Hala ere, aplikazio horien egitura ezagutzeak lehendik dauden programak aukeratzen lagunduko du. Prozesuetan oinarritutako sistemak harian oinarritutako sistemekin eta gertaeretan oinarritutakoekin alderatu ahal izango dituzu. Ulertuko duzu eta baloratuko duzu zergatik Nginx-ek Apache httpd baino hobeto funtzionatzen duen, zergatik Tornado oinarritutako Python aplikazio batek erabiltzaile gehiago balio dezakeen Django oinarritutako Python aplikazio batekin alderatuta.

ZeroHTTPd: Ikasteko tresna

ZeroHTTPd C-n hutsetik idatzi dudan web zerbitzari bat da irakaskuntza tresna gisa. Ez du kanpoko menpekotasunik, Rediserako sarbidea barne. Gure Redis prozedurak egiten ditugu. Ikus behean xehetasun gehiagorako.

Teoria luzez eztabaida genezakeen arren, ez dago kodea idaztea, exekutatzea eta zerbitzarien arkitektura guztiak elkarren artean alderatzea baino hoberik. Hau da metodorik nabarmenena. Hori dela eta, ZeroHTTPd web zerbitzari soil bat idatziko dugu eredu bakoitza erabiliz: prozesuetan oinarritutakoa, harian oinarritutakoa eta gertaeretan oinarritutakoa. Ikus dezagun zerbitzari horietako bakoitza eta ikus dezagun nola funtzionatzen duten elkarren aldean. ZeroHTTPd C fitxategi bakar batean inplementatzen da. Gertaeretan oinarritutako zerbitzariak barne hartzen ditu uthash, goiburuko fitxategi bakarrean datorren hash taula inplementazio bikaina. Beste kasu batzuetan, ez dago menpekotasunik, proiektua ez zailtzeko.

Kodean iruzkin asko daude ulertzen laguntzeko. Kode lerro gutxitan web zerbitzari soil bat izanik, ZeroHTTPd web garapenerako gutxieneko esparrua ere bada. Funtzionalitate mugatuak ditu, baina fitxategi estatikoak eta orri "dinamiko" oso sinpleak hornitzeko gai da. ZeroHTTPd errendimendu handiko Linux aplikazioak nola sortzen ikasteko ona dela esan behar dut. Oro har, web-zerbitzu gehienek eskaerak itxaroten dituzte, egiaztatu eta prozesatu. Hauxe da ZeroHTTPd-ek egingo duena. Hau ikasteko tresna da, ez produkzioa. Erroreak kudeatzeko ez da ona eta nekez harrotuko ditu segurtasun-praktika onenak (bai, erabili nuen strcpy) edo C hizkuntzaren trikimailu burutsuak. Baina bere lana ondo egitea espero dut.

ZeroHTTPd hasierako orria. Fitxategi mota desberdinak atera ditzake irudiak barne

Bisita-liburuaren aplikazioa

Web aplikazio modernoak normalean ez dira fitxategi estatikoetara mugatzen. Interakzio konplexuak dituzte hainbat datu-base, cache eta abarrekin. Beraz, "Guest Book" izeneko web aplikazio soil bat sortuko dugu non bisitariek sarrerak beren izenen azpian uzten dituzten. Gonbidatuen liburuak lehenago utzitako sarrerak gordetzen ditu. Bisitarien kontagailua ere badago orriaren behealdean.

Web aplikazioa "Guest Book" ZeroHTTPd

Bisitarien kontagailua eta gonbidatuen liburuko sarrerak Redis-en gordetzen dira. Redis-ekin komunikatzeko, prozedura propioak ezartzen dira; ez daude kanpoko liburutegiaren menpe. Ez naiz oso zalea homebrew kodea zabaltzea publikoki eskuragarri dauden eta ondo probatutako irtenbideak daudenean. Baina ZeroHTTPd-en helburua Linuxen errendimendua eta kanpoko zerbitzuetarako sarbidea aztertzea da, HTTP eskaerak zerbitzatzeak errendimenduaren eragin handia duen bitartean. Redis-ekin komunikazioak guztiz kontrolatu behar ditugu gure zerbitzari-arkitektura bakoitzean. Arkitektura batzuetan blokeo deiak erabiltzen ditugu, beste batzuetan gertaeretan oinarritutako prozedurak erabiltzen ditugu. Kanpoko Redis bezero liburutegi bat erabiltzeak ez du kontrol hori emango. Gainera, gure Redis bezero txikiak funtzio batzuk baino ez ditu egiten (gako bat lortzea, ezartzea eta gehitzea; array bat lortzea eta gehitzea). Horrez gain, Redis protokoloa oso dotorea eta sinplea da. Ez duzu bereziki irakatsi beharrik ere. Protokoloak ehun bat kode lerrotan lan guztia egiteak erakusten du zein ondo pentsatuta dagoen.

Bezeroak (arakatzaileak) eskatzen duenean aplikazioak zer egiten duen erakusten du hurrengo irudiak /guestbookURL.

Gonbidatu liburuaren aplikazioak nola funtzionatzen duen

Bisita-liburuaren orri bat igorri behar denean, fitxategi sistemara dei bat dago txantiloia memorian irakurtzeko eta sareko hiru dei Redis-era. Txantiloi-fitxategiak goiko pantaila-argazkiko orriaren HTML eduki gehiena dauka. Edukiaren zati dinamikorako leku-mark bereziak ere badaude: argitalpenak eta bisitarien kontagailua. Redisengandik jasotzen ditugu, orrialdean txertatzen ditugu eta bezeroari guztiz osaturiko edukia eskaintzen diogu. Redis-i hirugarren deia saihestu daiteke, Redis-ek gako-balio berria itzultzen duelako gehitzen denean. Hala ere, gertaeretan oinarritutako arkitektura asinkronoa duen gure zerbitzariarentzat, sareko dei asko proba ona dira ikasteko helburuetarako. Beraz, Redis bisitari kopuruaren itzulera balioa baztertu eta aparteko dei batekin kontsultatzen dugu.

Zerbitzarien arkitekturak ZeroHTTPd

ZeroHTTPd-ren zazpi bertsio eraikitzen ari gara funtzionalitate berdinarekin baina arkitektura ezberdinekin:

Iteratiboa
Fork zerbitzaria (haur prozesu bat eskaera bakoitzeko)
Pre-fork zerbitzaria (prozesuen aurre-fork)
Exekuzio hariak dituen zerbitzaria (hari bat eskaera bakoitzeko)
Aurre-haria sortu duen zerbitzaria
Arkitektura oinarritua poll()
Arkitektura oinarritua epoll

Arkitektura bakoitzaren errendimendua neurtzen dugu zerbitzaria HTTP eskaerak kargatuz. Baina arkitektura oso paraleloak alderatzean, kontsulta kopurua handitzen da. Hiru aldiz probatzen dugu eta batez bestekoa kalkulatzen dugu.

Proba metodologia

ZeroHTTPd karga-probaren konfigurazioa

Garrantzitsua da probak exekutatzen direnean osagai guztiak makina berean ez exekutatzen. Kasu honetan, sistema eragileak programazio gehigarria eragiten du osagaiak CPUrako lehiatzen diren heinean. Aukeratutako zerbitzari-arkitektura bakoitzaren sistema eragilearen gainkostua neurtzea da ariketa honen helburu garrantzitsuenetako bat. Aldagai gehiago gehitzea prozesurako kaltegarria izango da. Hori dela eta, goiko irudiko ezarpenak funtzionatzen du onena.

Zer egiten du zerbitzari horietako bakoitzak?

load.unixism.net: Hemen exekutatzen gara ab, Apache Benchmark erabilgarritasuna. Gure zerbitzarien arkitekturak probatzeko behar den karga sortzen du.
nginx.unixism.net: Batzuetan, zerbitzari-programa baten instantzia bat baino gehiago exekutatu nahi dugu. Horretarako, ezarpen egokiak dituen Nginx zerbitzariak datorren karga-orekatzaile gisa funtzionatzen du ab gure zerbitzariaren prozesuetara.
zerohttpd.unixism.net: Hemen gure zerbitzari-programak zazpi arkitektura ezberdinetan exekutatzen ditugu, banan-banan.
redis.unixism.net: zerbitzari honek Redis deabrua exekutatzen du, non bisitarien sarrerak eta bisitarien kontagailuak gordetzen diren.

Zerbitzari guztiak prozesadorearen nukleo berean exekutatzen dira. Ideia arkitektura bakoitzaren errendimendu maximoa ebaluatzea da. Zerbitzariaren programa guztiak hardware berean probatzen direnez, hau da konparaziorako oinarria. Nire probako konfigurazioa Digital Ocean-ek alokatutako zerbitzari birtualek osatzen dute.

Zer neurtzen ari gara?

Adierazle desberdinak neur ditzakezu. Konfigurazio jakin batean arkitektura bakoitzaren errendimendua ebaluatzen dugu zerbitzariak paralelismo-maila ezberdinetako eskaerak kargatuz: karga 20 izatetik 15 erabiltzaile aldiberekora hazten da.

Probaren emaitzak

Hurrengo grafikoan zerbitzarien errendimendua erakusten da arkitektura ezberdinetan paralelismo maila ezberdinetan. Y ardatza segundoko eskaera kopurua da, x ardatza konexio paraleloak.

Jarraian emaitzen taula bat dago.

segundoko eskaerak

paralelismoa
errepikakorra
sardexka
aurreko sardexka
erreproduzitzen
aurre-streaming
inkesta
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
zabalkunde handia
2138

5000
-
zabalkunde handia
1600
1100
2519
-
2235

8000
-
-
1200
zabalkunde handia
2451
-
2100

10
-
-
zabalkunde handia
-
2200
-
2200

11
-
-
-
-
2200
-
2122

12
-
-
-
-
970
-
1958

13
-
-
-
-
730
-
1897

14
-
-
-
-
590
-
1466

15
-
-
-
-
532
-
1281

Grafikoan eta taulan ikus daiteke aldibereko 8000 eskaeraren gainetik bi jokalari baino ez zaizkigula geratzen: pre-fork eta epoll. Karga handitzen den heinean, inkestetan oinarritutako zerbitzari batek errendimenduko batek baino errendimendu txarragoa du. Haria sortu aurreko arkitektura epoll egiteko lehiakide duina da, Linux kernelak hari kopuru handiak programatzen dituenaren erakusgarri.

ZeroHTTPd iturburu kodea

ZeroHTTPd iturburu kodea Hemen. Arkitektura bakoitzerako direktorio bereizia dago.

ZeroHTTPd │ ├── 01_iteratiboa │ ├── main.c ├── 02_sardeketa │ ├── main.c ├── ── 03_preforking │────── 04_ haria │ ├── main.c ├── 05_prethreading │ ├── main.c ├── 06_poll │ ├── main.c ├── 07_epoll │ └── main.c ── publiko egin fitxategia ──├├─ ├── aurkibidea .html │ └── tux png └── txantiloiak └── bisita liburua └── index.html

Arkitektura guztietarako zazpi direktorioz gain, beste bi daude goi-mailako direktorioan: publikoa eta txantiloiak. Lehenengoak index.html fitxategia eta lehen pantaila-argazkiko irudia ditu. Beste fitxategi eta karpeta batzuk jar ditzakezu bertan, eta ZeroHTTPd fitxategi estatiko horiek arazorik gabe zerbitzatu beharko lituzke. Arakatzailearen bidea karpeta publikoko bidearekin bat badator, ZeroHTTPd-ek index.html fitxategia bilatzen du direktorio honetan. Gonbidatu liburuaren edukia dinamikoki sortzen da. Hasierako orri bat baino ez du, eta bere edukia 'templates/guestbook/index.html' fitxategian oinarritzen da. ZeroHTTPd-ek erraz gehitzen ditu orri dinamikoak luzapenerako. Ideia da erabiltzaileek txantiloiak gehi ditzaketela direktorio honetan eta ZeroHTTPd heda dezaketela behar bezala.

Zazpi zerbitzariak eraikitzeko, exekutatu make all goi-mailako direktoriotik - eta eraikuntza guztiak direktorio honetan agertuko dira. Fitxategi exekutagarriak abiarazten diren direktorio publikoak eta txantiloiak bilatzen dituzte.

Linux APIa

Ez duzu Linux APIa ondo ezagutu behar artikulu sail honetako informazioa ulertzeko. Hala ere, gai honi buruz gehiago irakurtzea gomendatzen dut; Interneten erreferentzia-baliabide asko daude. Linux APIen hainbat kategoria ukituko baditugu ere, gure arreta prozesuak, hariak, gertaerak eta sareko pila izango dira nagusiki. Linux APIari buruzko liburu eta artikuluez gain, mana irakurtzea gomendatzen dut sistema-deiak eta erabilitako liburutegi-funtzioetarako.

Errendimendua eta Eskalagarritasuna

Errendimenduari eta eskalagarritasunari buruzko ohar bat. Teorian, ez dago haien artean loturarik. Oso ondo funtzionatzen duen web-zerbitzu bat izan dezakezu, milisegundo gutxiko erantzun-denbora duena, baina ez da batere eskalatzen. Era berean, errendimendu txarreko web-aplikazio bat egon daiteke, segundo batzuk behar dituena erantzuteko, baina hamarnaka eskalatzen du aldibereko hamarnaka erabiltzaile kudeatzeko. Hala ere, errendimendu handiko eta eskalagarritasunaren konbinazioa oso konbinazio indartsua da. Errendimendu handiko aplikazioek, oro har, baliabideak neurriz erabiltzen dituzte eta, horrela, zerbitzarian aldibereko erabiltzaile gehiago zerbitzatzen dituzte, kostuak murriztuz.

CPU eta I/O zereginak

Azkenik, informatikan beti daude bi zeregin mota posible: I/O eta CPUrako. Eskaerak Internet bidez jasotzea (sareko I/O), fitxategiak zerbitzatzea (sarea eta diskoko I/O), datu-basearekin komunikatzea (sarea eta diskoko I/O) I/O jarduerak dira. Datu-baseen kontsulta batzuk CPU intentsiboa izan dezakete (ordenatzea, milioi bat emaitzaren batez bestekoa, etab.). Web-aplikazio gehienak ahalik eta I/O gehienez mugatuta daude, eta prozesadorea oso gutxitan erabiltzen da gaitasun osoan. I/O ataza batzuk CPU asko erabiltzen ari direla ikusten duzunean, ziurrenik aplikazioen arkitektura eskasaren seinale da. Horrek esan nahi du PUZaren baliabideak alferrik galtzen direla prozesuen kudeaketan eta testuingurua aldatzean, eta hori ez da guztiz erabilgarria. Irudien prozesamendua, audio fitxategien bihurketa edo ikaskuntza automatikoa bezalako zerbait egiten ari bazara, orduan aplikazioak CPU baliabide indartsuak behar ditu. Baina aplikazio gehienetan ez da horrela gertatzen.

Lortu informazio gehiago zerbitzarien arkitekturei buruz

Iturria: www.habr.com

Linux sareko aplikazioen errendimendua. Sarrera