Veebirakendused on tänapäeval laialdaselt kasutusel ning HTTP hõlmab suure osa kõigist transpordiprotokollidest. Veebirakenduste arendamise nüansse uurides pöörab enamik inimesi väga vähe tähelepanu operatsioonisüsteemile, kus need rakendused tegelikult töötavad. Arenduse (Dev) ja operaatori (Ops) eristamine on olukorda ainult halvendanud. Kuid DevOpsi kultuuri levikuga hakkavad arendajad võtma vastutust oma rakenduste käivitamise eest pilves, seega on neile väga kasulik põhjalikult tutvuda operatsioonisüsteemi tagumise poolega. See on eriti oluline, kui proovite süsteemi seadistada tuhandete või kümnete tuhandete samaaegsete ühenduste jaoks.

Veebiteenuste piirangud on väga sarnased teiste rakenduste piirangutega. Olgu need koormuse tasakaalustajad või andmebaasirakendused, kõigil neil rakendustel on sarnased probleemid kõrgvõimekuses keskkonnas. Nende põhipiirangute ja nende ületamise meetodite mõistmine aitab üldiselt hinnata teie veebirakenduste jõudlust ja skaleeritavust.

Ma kirjutan seda artiklite seeriat vastuseks noorte arendajate küsimustele, kes soovivad saada hästi informeeritud süsteemi arhitektideks. Pole võimalik selgelt mõista Linuxi rakenduste optimeerimise meetodeid, ilma et sukelduda aluspõhimõtetesse, kuidas need töötavad operatsioonisüsteemi tasandil. Kuigi rakenduste tüüpe on palju, tahan selles tsüklis uurida võrgurakendusi, mitte töölauarakendusi nagu brauserid või tekstiredaktorid. See materjal on suunatud arendajatele ja arhitektidele, kes soovivad mõista, kuidas Linuxi või Unix rakendused töötavad ja kuidas neid kõrge jõudluse saavutamiseks struktureerida.

Linux on serveri operatsioonisüsteem, ning enamasti töötavad teie rakendused just sellel OS-il. Kuigi ma räägin 'Linuxist', võite enamiku ajast kindlalt eeldada, et mõeldakse kõiki Unixiga sarnaseid operatsioonisüsteeme tervikuna. Siiski ei ole ma kaasasolevat koodi testinud teistes süsteemides. Seega, kui teid huvitab FreeBSD või OpenBSD, võivad tulemused erineda. Kui proovin midagi Linuxiga seotud, siis mainin seda.

Kuigi saate omandatud teadmisi kasutada rakenduse loomiseks nullist ja see võib olla suurepäraselt optimeeritud, on parem seda mitte teha. Kui kirjutate oma organisatsiooni äri rakenduse jaoks uue veebiserveri C või C++ keeles, võib see olla teie viimane tööpäev. Siiski aitab nende rakenduste struktuuri tundmine valida juba olemasolevaid programme. Saate võrrelda protsessidele põhinevaid süsteeme, voogude ja sündmuste põhiseid süsteeme. Te mõistate ja hindate, miks Nginx töötab paremini kui Apache httpd ning miks Tornado põhinev Python rakendus suudab teenindada rohkem kasutajaid võrreldes Django põhise Python rakendusega.

ZeroHTTPd: õppimistööriist

ZeroHTTPd — veebiserver, mille ma kirjutasin nullist C keeles kui õppevahend. Sellel ei ole väliseid sõltuvusi, sealhulgas juurdepääsu Redis'ile. Käivitame oma Redis protseduurid. Lisateave allpool.

Kuigi me saaksime kaua arutada teooriat, pole midagi paremat kui koodi kirjutamine, selle käivitamine ja kõikide serveri arhitektuuride omavaheline võrdlemine. See on kõige ilmsem meetod. Seetõttu kirjutame lihtsa veebiserveri ZeroHTTPd, rakendades iga mudelit: protsesside, voogude ja sündmuste põhjal. Kontrollime igat nende serverit ja vaatame, kuidas nad üksteisega võrreldes toimivad. ZeroHTTPd on rakendatud ühes C-failis. Sündmuste põhise serveri koosseis sisaldab uthash, suurepärane hash-tabeli teostus, mis tuleb ühes pealkirjafailis. Muudel juhtudel ei ole mingeid sõltuvusi, et projekti mitte keerulisemaks muuta.

Koodis on palju kommentaare, et aidata mõista. Tulles välismaailmast, on ZeroHTTPd ka lihtne veebiarenduse raamistik. Selle funktsionaalsus on piiratud, kuid see suudab edastada 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. Suures plaanis ootavad enamik veebiteenuseid päringute esitamist, kontrollimist ja töötlemist. Just seda teebki ZeroHTTPd. See on õppimistööriist, mitte tootmisvahend. See ei ole tugev vigade töötlemisel ja tõenäoliselt ei uhkusta see parimate turvapraktikatega (jah, ma kasutasin strcpy) või keerukate keelte trikiga C. Kuid ma loodan, et ta teeb oma ülesannet hästi.

ZeroHTTPd eelolev leht. See suudab edastada erinevat tüüpi faile, sealhulgas pilte.

Külastuste raamat rakendus

Kaasaegsed veebirakendused ei piirduma lihtsalt staatiliste failidega. Neil on keerulised suhted erinevate andmebaaside, vahemäcachede jne. Seetõttu loome lihtsa veebirakenduse nimega „Külastuste raamat“, kus külastajad jätavad oma nimede all sõnumeid. Külastuste raamatus salvestatakse varem jäetud sõnumid. Lehe allosas on samuti külastajate loend.

ZeroHTTPd Külastuste raamat veebirakendus

Külastajate loend ja külastuste raamatu sõnumid salvestatakse Redis. Redisiga suhtlemiseks on rakendatud meie enda protseduurid, need ei sõltu välistest raamatukogudest. Ma ei ole suur sõber, kes kirjutab koju tellitud koodi, kui olemas on avalikud ja hästi testitud lahendused. Kuid ZeroHTTPdi eesmärk on õppida Linuxi jõudlust ja juurdepääsu välistest teenustest, samas kui HTTP-päringute haldamine mõjutab tõsiselt jõudlust. Me peame saama täieliku kontrolli Redisiga suhtlemise üle meie serveri arhitektuurides. Ühes arhitektuuris kasutame blokeerivaid kutsunge, teistes - sündmuste põhiseid protseduure. Väline Redis klientraamatukogu ei anna sellist kontrolli. Lisaks täidab meie väike Redis klient vaid mõnda funktsiooni (saamine, seadistamine ja võtme suurendamine; saamine ja lisamine massiivi). Lisaks sellele on Redis protokoll äärmiselt elegantne ja lihtne. Selle õppimiseks ei pea isegi erilist vaeva nägema. Fakt, et kogu töö, mida protokoll täidab, on umbkaudu sadades lähtekoodiread, näitab, kui hästi see on läbi mõeldud.

Järgmises joonises on näidatud rakenduse tegevust, kui klient (brauser) teeb taotluse /guestbookURL.

Külastuste raamat rakenduse töömehhanism

Kui tuleb välja anda külalisraamatuleht, toimub üks süsteemikutsung faili süsteemile, et lugeda mall mälu ning kolm võrgu kutsungit Redis’esse. Mallifail sisaldab suure osa HTML-i sisust lehe jaoks, mis on ülaltoodud ekraanipildil. Seal on ka spetsiaalsed kohandajad dünaamilise sisu osa jaoks: postitused ja külastajate loendur. Saame need Redis'est, sisestame lehele ja edastame kliendile täielikult vormistatud sisu. Kolmandast Redis'e kutsungist saab loobuda, kuna Redis tagastab võtme uue väärtuse ka siis, kui seda suurendame. Siiski on meie sündmustepõhise asünkroonse arhitektuuri jaoks palju võrgu kutseid hea katse eesmärkidel. Seega loobume Redis'e tagastatud väärtusest külastajate arvu kohta ja küsime selle eraldi kutsega.

ZeroHTTPd serveri arhitektuurid

Ehime seitse versiooni ZeroHTTPd’st, millel on sama funktsionaalsus, kuid erinevad arhitektuurid:

• Iteratiivne
• Fork server (üks tütartöötlus päringu kohta)
• Pre-fork server (protsesside eelne kogumine)
• Server täitmisniidiga (üks niit päringu kohta)
• Server eelnevalt loodud niitidega
• Arhitektuur, mis põhineb poll()
• Arhitektuur, mis põhineb epoll

Käime iga arhitektuuri jõudlust HTTP-päringutega koormates. Kuid kõrge paralleelsuse arhitektuuride võrdlemisel suureneb päringute arv. Testime kolm korda ja arvutame keskmise.

Testimise metodologia

ZeroHTTPd koormustestimise seadmed

Oluline on, et testimise ajal ei töötaks kõik komponendid ühes masinas. Sel juhul kannab operatsioonisüsteem lisakoormust ajastamisel, kuna komponendid konkureerivad CPU pärast. Operatsioonisüsteemi koormuse mõõtmine igas valitud serveri arhitektuuris on see harjutuse üks olulisemaid eesmärke. Liigsete muutujate lisamine kahjustab protsessi. Seega töötab ülaltoodud seade kõige paremini.

Mida igaüks neist serveritest teeb

• load.unixism.net: siin käivitame ab, Apache Benchmarki tööriista. See genereerib koormuse, mis on vajalik meie serveri arhitektuuride testimiseks.
• nginx.unixism.net: mõnikord soovime käivitada rohkem kui ühe serveriprogrammi koopia. Selleks töötab Nginx server koos vastavate seadistustega koormuse tasakaalustajana, mis tuleb ab meie serveriprotsessidesse.
• zerohttpd.unixism.net: siin käivitame meie serveriprogrammid seitsmes erinevas arhitektuuris, ühte korraga.
• redis.unixism.net: sellel serveril töötab Redis deemon, kus talletatakse külalisteraamat ja külastajate arvesti.

Kogu serverid töötavad ühes protsessori tuumas. Idee on hinnata igas arhitektuuris maksimaalset jõudlust. Kuna kõik serveriprogrammid testitakse samal riistvaral, on see nende võrdlemise baas. Minu testimist seadistus koosneb Digital Ocean'ilt renditud virtuaalserveritest.

Mida me mõõdame?

Erinevaid näitajaid on võimalik mõõta. Hinnatakse iga arhitektuuri jõudlust antud konfiguratsioonis, koormates servereid päringutega erinevatel paralleelsuse tasemetel: koormus kasvab 20-st kuni 15 000 samaaegse kasutajani.

Testi tulemused

Järgmises diagrammis on kujutatud serverite jõudlust erinevates arhitektuurides erinevatel paralleelsuse tasemetel. Y-teljel on päringud sekundis, X-teljel on paralleelsed ühendused.

Allpool on tabel tulemustega.

päringud sekundis

paralleelsus
iteratiivne
fork
ennehargne
sugemetoodika
enne-sugemetoodika
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
suurem hajuvus
2138

5000
–
suurem hajuvus
1600
1100
2519
–
2235

8000
–
–
1200
suurem hajuvus
2451
–
2100

10 000
–
–
suurem hajuvus
–
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 nähtub, et üle 8000 samaaegse päringu korral jääb meil alles vaid kaks mängijat: ennehargne ja epoll. Koormuse kasvades töötab poll-põhine server halvemini kui sugemetoodika. Enehargne arhitektuur on epollile vääriliseks konkurendiks: see tõestab, kui hästi Linuxi tuum suudab planeerida suurtes kogustes niite.

ZeroHTTPd lähtekood

ZeroHTTPd lähtekood siin. Iga arhitektuuri jaoks eraldi kataloog.

ZeroHTTPd
│
├── 01_iteratiivne
│   ├── main.c
├── 02_hargnev
│   ├── main.c
├── 03_ennehargnev
│   ├── main.c
├── 04_sugemetoodika
│   ├── main.c
├── 05_enne-sugemetoodika
│   ├── main.c
├── 06_poll
│   ├── main.c
├── 07_epoll
│    └── main.c
├── Makefile
├── public
│   ├── index.html
│   └── tux.png
└── templates
    └── guestbook
        └── index.html

Lisaks seitsmele kataloogile, mis on mõeldud kõigile arhitektuuridele, on ülemises kataloogis veel kaks: public ja templates. Esimese sees asub fail index.html ja pilt esimeselt ekraanipildilt. Sinna võib panna ka teisi faile ja kaustu, ning ZeroHTTPd peaks need staatilised failid probleemideta välja andma. Kui brauseri path vastab public kaustas olevale teele, siis otsib ZeroHTTPd sellest kataloogist faili index.html. Külastusraamatule mõeldud sisu genereeritakse dünaamiliselt. Sellel on ainult avaleht, mille sisu põhineb failil ‘templates/guestbook/index.html’. ZeroHTTPd-sse on lihtne lisada dünaamilisi lehti laiendamiseks. Idee seisneb selles, et kasutajad saavad selle katalooge lisada malle ja laiendada ZeroHTTPd-d vastavalt vajadusele.

Seitsme serveri kokkupanekuks käivitage make all ülemise kataloogi sees — ja kõik buildid ilmuvad sellesse kataloogi. Täidetavad failid otsivad public ja templates kaustu selles kataloogis, kust need käivitatakse.

Linux API

Selle artiklite seeria teabe mõistmiseks ei pea Linux API-s väga hästi orienteeruma. Soovitan siiski lugeda selle kohta rohkem, veebis on palju abimaterjale. Kuigi me käsitleme mitmeid Linux API kategooriaid, keskendub meie tähelepanu peamiselt protsessidele, lõimele, sündmustele ja võrgu kihtidele. Peale raamatute ja artiklite Linux API-st soovitan ka lugeda süsteemikõnede ja kasutatavate teekide funktsioonide manasid.

Jõudlus ja skaleeritavus

Üks märkus jõudluse ja skaleeritavuse kohta. Teoreetiliselt pole nende vahel mingit seost. Teil võib olla veebiteenus, mis töötab väga hästi, vastusaegadega mõne millisekundi jooksul, kuid see ei skaleeru üldse. Samuti võib olla halvasti toimiv veebirakendus, mis vajab vastamiseks mitu sekundit, kuid see on skaleeritav kümnete suhtes, et hallata kümneid tuhandeid samaaegseid kasutajaid. Teiselt poolt, kõrge jõudluse ja skaleeritavuse kombinatsioon on väga võimas. Kõrge jõudlusega rakendused kasutavad ressursse üldiselt säästlikult ja seega teenindavad tõhusalt rohkem samaaegseid kasutajaid serveris, vähendades kulusid.

CPU ja I/O ülesanded

Lõpuks on arvutustes alati kaks võimalikku ülesannet: I/O ja CPU jaoks. Interneti kaudu päringute saamine (võrgu sisend-väljund), failide haldamine (võrgu ja kettasisend-väljund), andmebaasiga suhtlemine (võrgu ja kettasisend-väljund) - kõik need on I/O tegevused. Mõned andmebaasi päringud võivad veidi koormata CPU-d (järjestamine, miljoni tulemuse keskmise arvutamine jne). Enamik veebirakendusi on piiratud maksimaalse võimaliku I/O-ga, samas kui protsessorit harva kasutatakse täielikult. Kui märkate, et mõnes sisend-väljundi ülesandes kasutatakse palju CPU-d, on tõenäoliselt tegemist halva rakenduse arhitektuuri tunnusega. See võib tähendada, et CPU ressursid kuluvad protsesside juhtimisele ja konteksti vahetamisele - ja see pole kuigi kasulik. Kui teete midagi nagu pilditöötlus, helifailide konverteerimine või masinõpe, siis nõuab rakendus võimsaid CPU ressursse. Kuid enamik rakendusi ei nõua seda.

Üksikasjalikumalt serveri arhitektuuridest

1. Osa I. Iteratiivne arhitektuur
2. Osa II. Fork-serverid
3. Osa III. Pre-fork serverid
4. Osa IV. Serverid täitmisvoogudega
5. Osa V. Serverid eelnevalt loodud voogudega
6. Osa VI. Poll-põhine arhitektuur
7. Osa VII. epoll-põhine arhitektuur

Allikas: habr.com