Veebirakendusi kasutatakse praegu igal pool ja HTTP domineeib kõiki edastusprotokolle. Veebirakenduste arendamise nüansse uurides pööravad paljud tähelepanu väga vähe sellele operatsioonisüsteemile, kus need rakendused tegelikult töötavad. Arenduse (Dev) ja opereerimise (Ops) eristaminen on olukorda veelgi halvendanud. Kuid DevOpsi kultuuri levikuga hakkavad arendajad vastutama oma rakenduste käivitamise eest pilves, seega on väga kasulik süveneda operatsioonisüsteemi taustsüsteemi tundmisse. See on eriti kasulik, kui proovite üles seada süsteemi tuhandete või kümnete tuhandete samaaegsete ühenduste jaoks.

Veebiteenuste piirangud on väga sarnased teiste rakenduste piirangutega. Olgu need koormuse tasakaalustajad või andmebaasiserverid, kõikidel neil rakendustel on sarnased probleemid kõrge jõudlusega keskkonnas. Nende põhiliste piirangute mõistmine ja nende ületamise viiside leidmine võimaldab üldiselt hinnata teie veebirakenduste jõudlust ja skaleeritavust.

Kirjutan seda artiklite seeriat vastuseks noorte arendajate küsimustele, kes soovivad saada teadlikeks süsteemi arhitektideks. Linuxi rakenduste optimeerimise meetodeid ei saa selgelt mõista, kui ei süüvi nende aluspõhimõtetesse, kuidas need töötavad operatsioonisüsteemi tasemel. Kuigi rakenduste tüüpe on palju, soovin antud tsüklis uurida just võrgu rakendusi, mitte töölauarakendusi nagu brauserid või tekstiredaktorid. See materjal on mõeldud arendajatele ja arhitektidele, kes soovivad mõista, kuidas töötavad Linuxi või Unix programmid ning kuidas neid kõrge jõudluse nimel struktureerida.

Linux on serveripõhine operatsioonisüsteem, ja kõige sagedamini töötavad teie rakendused just sellel OS-il. Kuigi räägin "Linuxist", võite suurema osa ajast kindlalt eeldada, et silmas peetakse kõiki Unix-tüüpi operatsioonisüsteeme. Siiski, ma ei ole kaasnevat koodi testinud teistel süsteemidel. Nii et kui teid huvitab FreeBSD või OpenBSD, võivad tulemused erineda. Kui proovin midagi, mis on Linuxile spetsiifiline, annan sellest teada.

Kuigi saate omandatud teadmisi kasutada rakenduse loomiseks nullist, mis on suurepäraselt optimeeritud, ei ole soovitatav seda teha. Kui kirjutate oma organisatsiooni ärirakendusele uue veebi-serveri C või C++ keeles, võib see olla teie viimane tööpäev. Siiski aitab selliste rakenduste struktuuri tundmine valida juba olemasolevaid programme. Saate võrrelda protsessipõhiseid süsteeme voogude- ja sündmuspõhiste süsteemidega. Te mõistate ja hindate, miks Nginx töötab paremini kui Apache httpd, miks Python Tornado baasil töötav rakendus suudab teenindada rohkem kasutajaid võrreldes Python Django baasil töötava rakendusega.

ZeroHTTPd: õppevahend

ZeroHTTPd — veebi-server, mille kirjutasin nullist C keeles õppevahendina. Sellel ei ole väliseid sõltuvusi, sealhulgas juurdepääsu Redis'ele. Käivitame oma Redise protseduurid. Lisainfot leiate allpool.

Kuigi me võiksime pikka aega arutada teooriat, ei ole miski parem kui kirjutada kood, käivitada see ja võrrelda erinevaid serveri arhitektuure. See on kõige näitlikum meetod. Seetõttu kirjutame lihtsa veebiserveri ZeroHTTPd, rakendades igat mudelit: protsesside, niitide ja sündmuste põhjal. Kontrollime igaüht neist serveritest ja vaatame, kuidas nad omavahel võrreldes toimivad. ZeroHTTPd on teostatud ühes C-failis. Sündmuspõhise serveri koosseisu kuulub uthash, suurepärane hash-tabeli teostus, mis tarnitakse ühes päistefailis. Muude osade puhul ei ole mingeid sõltuvusi, et mitte projekti keeruliseks teha.

Koodis on palju kommentaare, mis aitavad arusaamist. ZeroHTTPd on lihtne veebiserver, mis koosneb vaid mõnest koodireast ja esindab ka minimaalset raamistikku veebiarenduseks. Selle funktsionaalsus on piiratud, kuid see suudab serveerida staatilisi faile ja väga lihtsaid 'dünaamilisi' lehti. Pean ütlema, et ZeroHTTPd sobib hästi õppimiseks, kuidas luua kõrge jõudlusega Linuxi rakendusi. Üldiselt ootavad enamik veebiteenuseid päringute täitmist, kontrollivad neid ja töötlevad. Just seda teebki ZeroHTTPd. See on õppevahend, mitte tootmisriist. See ei ole tugev vigade töötlemises ja ei pruugi uhkustada parimate turvapraktikatega (oh jah, ma kasutasin strcpy) või keerukate C-keele trikkidega. Kuid ma loodan, et see täidab oma ülesannet hästi.

ZeroHTTPd pealeht. See suudab esitada erinevaid failitüüpe, sealhulgas pilte.

Külastusraamatu rakendus

Kaasaegsed veebirakendused ei piirdu tavaliselt staatiliste failidega. Neil on keerukad interaktsioonid erinevate andmebaaside, cache'ide jne. Seetõttu loome lihtsa veebirakenduse nimega „Külastusraamat”, kus külastajad saavad jätta oma nime all kirjeid. Külastusraamat hoiab varasemaid kirjeid. Lehe alumises osas on ka külastajate loendur.

Veebirakendus „Külastusraamat” ZeroHTTPd

Külastuste arvesti ja külalisteraamatu salvestamine toimub Redis'is. Kommunikatsioonide haldamiseks Redis'iga on välja töötatud kohandatud protseduurid, mis ei sõltu välistest raamatukogudest. Ma ei ole suur kodarenduse koodi pooldaja, kui on olemas avalikult saadaval ja hästi testitud lahendusi. Kuid ZeroHTTPd eesmärk on uurida Linuxi jõudlust ja juurdepääsu välistel teenustele, samas kui HTTP-päringute töötlemine mõjutab jõudlust tõsiselt. Me peame täielikult kontrollima suhtlust Redis'iga igas meie serveri arhitektuuris. Ühes arhitektuuris kasutame blokeerivaid kalle, teistes aga sündmuste põhiseid protseduure. Välist Redis'i kliendi raamatukogu kasutamine ei anna sellist kontrolli. Lisaks täidab meie väike Redis'i klient vaid mõningaid funktsioone (võtme saamine, seadmine ja suurendamine; massiivi saamine ja lisamine). Samuti on Redis'i protokoll äärmiselt elegantne ja lihtne. Selle õppimiseks ei pea isegi spetsiaalselt pingutama. Fakt, et kogu töö protokoll teeb umbes sada koodi rida, näitab, kui hästi see on läbi mõeldud.

Järgmises joonises on näidatud rakenduse toimingud, kui klient (brauser) teeb päringu /guestbookURL.

Külalisraamatukirjelduste rakenduse töömehhanism

Kui külalisraamatu lehte tuleb välja anda, toimub üks failisüsteemi kutsumine шаблонite lugemiseks mällu ning kolm võrgu kutsumist Redis'esse. Шаблонifail sisaldab suure osa HTML-i sisust, mis on ülemisel ekraanipildil. Seal on ka spetsiaalsed täitjatel dünaamilise sisu osa jaoks: postitused ja külastajate loendur. Me saame need Redis'est, paigutame lehele ja väljastame kliendile täielikult vormistatud sisu. Kolmandat Redis'e kutsumist saab vältida, kuna Redis tagastab võtme uue väärtuse suurendamisel. Kuid meie sündmustepõhise asünkroonne arhitektuuri korral pakuvad paljud võrgu kutsumised hästi õppimise eesmärkidel. Seega ei kasuta me külastajate arvu Redis'elt tagastatud väärtust, vaid küsime seda eraldi kutsumisega.

Serveri arhitektuurid ZeroHTTPd

Me ehitame seitse ZeroHTTPd versiooni sama funktsionaalsusega, kuid erineva arhitektuuriga:

• Iteratiivne
• Fork server (üks alamprotsess päringu kohta)
• Eelseise server (protsesside eelne vormimine)
• Server, kus on täitmisvoogudes (üks lõng päringu kohta)
• Server, kus on eelnevalt loodud vood
• Arhitektuur, millel on poll()
• Arhitektuur, millel on epoll

Mõõdame iga arhitektuuri jõudlust, laadides serverit HTTP päringutega. Kuid kõrge paralleelsuse korral suureneb päringute arv. Testime kolm korda ja arvutame keskmise.

Testimise metoodika

ZeroHTTPd koormustestimise seadistamine

Oluline on, et kõiki komponente ei käitataks samal masinal testide ajal. Sel juhul kannab operatsioonisüsteem täiendavaid kulusid ajakava tõttu, kuna komponendid konkureerivad CPU üle. Operatsioonisüsteemi kulude mõõtmine igas valitud serveri arhitektuuris on selle harjutuse üks olulisemaid eesmärke. Rohkemate muutujate lisamine halvendab protsessi. Seega töötab ülaltoodud seadistus kõige paremini.

Mis teeb iga nende serverite puhul

• load.unixism.net: siin käitame ab, Apache Benchmark utiliiti. See genereerib koormuse, mis on vajalik meie serveri arhitektuuride testimiseks.
• nginx.unixism.net: mõnikord soovime käitada rohkem kui ühte serveriprogrammi eksemplari. Selleks töötab Nginx server koos vastavate seadistustega koormuse jaoturina, mis jagab koormust ab meie serveriprotsessidele.
• zerohttpd.unixism.net: siin käitame meie serveriprogramme seitsme erineva arhitektuuri peal, ühte korraga.
• redis.unixism.net: sel serveril töötab Redis deemon, kus hoitakse külalisteraamatu kirjeid ja külastajate arvestit.

Kõik serverid töötavad ühe protsessori tuuma peal. Idee on hinnata iga arhitektuuri maksimaalset jõudlust. Kuna kõik serveriprogrammid testitakse sama riistvaral, on see nende võrdlemiseks alus. Minu testimisseade koosneb Digitaalsetest Ookeanist renditud virtuaalserveritest.

Mida me mõõdame?

Saame mõõta erinevaid näitajaid. Hindame iga arhitektuuri jõudlust antud konfiguratsioonis, koormates servereid erinevatel tasanditel: koormus tõuseb 20-st kuni 15 000 samal ajal oleva kasutaja juurde.

Testide tulemused

Järgmisel diagrammil on kujutatud serverite jõudlust erinevates arhitektuurides erinevatel paralleelsuse tasemetel. Y-telg näitab sekundis tehtavaid päringute arvu, X-telg aga paralleelseid ühendusi.

Allpool on tabel tulemuste kohta.

päringut sekundis

paralleelsus
iteraatiivne
forki
eelnevalt forkitud
keeruline
eelnevalt keeruline
poll
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
suure ulatusega
2138

5000
–
suure ulatusega
1600
1100
2519
–
2235

8000
–
–
1200
suure ulatusega
2451
–
2100

10 000
–
–
suure ulatusega
–
2200
–
2200

11 000
–
–
–
–
2200
–
2122

12 000
–
–
–
–
970
–
1958

13 000
–
–
–
–
730
–
1897

14 000
–
–
–
–
590
–
1466

15 000
–
–
–
–
532
–
1281

Diagrammist ja tabelist on näha, et üle 8000 samaaegse päringu juures jäävad meil alles vaid kaks arhitektuuri: eelnevalt forkitud ja epoll. Koormuse tõustes töötab poll-iga server halvemini kui keeruline. Eelnevalt loodud keerud pakkuvad kvaliteetset konkurentsi epoll-le: see tõestab, kui hästi Linuxi kernel suudab hallata suurt hulka keerukaid ülesandeid.

ZeroHTTPd allikakood

ZeroHTTPd allikakood siit. Iga arhitektuuri jaoks on eraldi kataloog.

ZeroHTTPd
│
├── 01_iterative
│   ├── main.c
├── 02_forking
│   ├── main.c
├── 03_preforking
│   ├── main.c
├── 04_threading
│   ├── main.c
├── 05_prethreading
│   ├── main.c
├── 06_poll
│   ├── main.c
├── 07_epoll
│    └── main.c
├── Makefile
├── public
│   ├── index.html
│   └── tux.png
└── templates
    └── guestbook
        └── index.html

Lisaks seitsmele kaustale kõigi arhitektuuride jaoks on ülemises kataloogis veel kaks: public ja templates. Esimeses asub fail index.html ja pilt esimesest ekraanipildist. Siia saab paigutada teisi faile ja kaustu ning ZeroHTTPd peab nende staatiliste failide edastamisega ilma probleemideta toime tulema. Kui brauseri tee vastab tee public kaustas, otsib ZeroHTTPd selle katalooge faili index.html. Külalisteraamatu sisu genereeritakse dünaamiliselt. Sellel on ainult peamine leht, mille sisu põhineb failil ‘templates/guestbook/index.html’. ZeroHTTPd-s on lihtne lisada dünaamilisi lehti laiendamiseks. Idee on, et kasutajad saavad selles kataloogis lisada malle ja laiendada ZeroHTTPd-d vastavalt vajadusele.

Seitsme serveri ehitamiseks käivitage make all ülemisest kataloogist — ja kõik versioonid ilmuvad selle katalooge. Täitevfailid otsivad kaustu public ja templates selles kataloogis, kust need käivitatakse.

Linux API

Selle artiklite tsükli teabe mõistmiseks ei ole vajalik väga hästi tunda Linux API-d. Soovitan siiski selle teema kohta rohkem lugeda, internetis on palju abimaterjale. Kuigi käsitleme mitmeid Linux API kategooriaid, keskendume peamiselt protsessidele, lõimedele, sündmustele ja võrgu stack'ile. Lisaks Linux API raamatutele ja artiklitele soovitan tutvuda ka süsteemikõnede ja kasutatavate teegifunktsioonide manuaalidega.

Toimivus ja skaleeritavus

Üks tähelepanek jõudluse ja mastaapsuse kohta. Teoreetiliselt ei ole nende vahel mingit seost. Teil võib olla veebiteenus, mis töötab väga hästi, reageerimisaeg mõne millisekundi jooksul, kuid see ei ole üldse mastaapne. Samuti võib olla halvasti töötav veebirakendus, mis vajab vastamiseks mitmeid sekundeid, kuid see mastaapub kümneteks, et jagada kümneid tuhandeid samal ajal kasutajaid. Siiski on kõrge jõudluse ja mastaapsuse kombinatsioon väga võimas. Kõrge jõudlusega rakendused kasutavad üldiselt ressursse säästlikult ja seega suudavad tõhusalt teenindada rohkem samal ajal olevaid kasutajaid serveris, vähendades kulusid.

CPU ja I/O ülesanded

Lõpuks on arvutustes alati kaks võimalikku ülesannete tüüpi: I/O ja CPU. Interneti kaudu päringute saamine (võrgu sisend-väljund), failide haldamine (võrgu ja ketta sisend-väljund), andmebaasiga suhtlemine (võrgu ja ketta sisend-väljund) — kõik need on I/O toimingud. Mõned andmebaasi päringud võivad veidi koormata CPU-d (sorteerimine, miljoni tulemuse keskmise arvutamine jne). Enamik veebirakendusi on piiratud maksimaalse võimaliku I/O-ga, protsessorit kasutatakse harva täielikult. Kui näete, et mingisuguses sisend-väljundi ülesandes kasutatakse palju CPU-d, on see tõenäoliselt halva rakenduse arhitektuuri märk. See võib tähendada, et CPU ressursse kasutatakse protsesside haldamiseks ja konteksti vahetamiseks — ja see ei ole kuigi kasulik. Kui teete midagi, nagu piltide töötlemine, helifailide konverteerimine või masinõpe, siis vajab rakendus võimsaid CPU ressursse. Aga enamik rakendusi ei vaja seda.

Rohkem teavet serveri arhitektuuride kohta

1. Osa I. Iteratiivne arhitektuur
2. Osa II. Fork-serverid
3. Osa III. Pre-fork serverid
4. Neljandik osa. Täidete serverid
5. Viiendik osa. Eeltäidete serverid
6. Kuues osa. Poll-põhine arhitektuur
7. Seitsmes osa. Epoll-põhine arhitektuur

Allikas: habr.com