Webapplikationer bruges nu overalt, og blandt alle transportprotokoller udgør HTTP størstedelen. Når man studerer detaljer i webapplikationsudvikling, bliver operativsystemet, hvor disse applikationer faktisk kører, ofte overset. Opdelingen mellem udvikling (Dev) og drift (Ops) har kun forværret situationen. Men med udbredelsen af DevOps-kulturen begynder udviklerne at påtage sig ansvaret for at køre deres applikationer i skyen, så det er meget nyttigt for dem at blive grundigt bekendt med backend'en i operativsystemet. Dette er især nyttigt, hvis du forsøger at implementere et system til tusindvis eller titusindvis af samtidige forbindelser.

Begrænsningerne i webtjenester ligner meget dem i andre applikationer. Uanset om det er belastningsbalance eller databaser, har alle disse applikationer lignende problemer i højtydende miljøer. At forstå disse grundlæggende begrænsninger og måder at overvinde dem på vil generelt tillade dig at vurdere ydeevnen og skalerbarheden af dine webapplikationer.

Jeg skriver denne serie artikler som svar på spørgsmål fra unge udviklere, der ønsker at blive velbevandrede systemarkitekter. Det er umuligt at forstå metoderne til optimering af Linux-applikationer uden at dykke ned i det grundlæggende, og hvordan de fungerer på operativsystemniveau. Selvom der findes mange typer applikationer, vil jeg i denne cyklus undersøge netværksapplikationer og ikke desktop-applikationer som browsere eller tekstbehandlere. Dette materiale er rettet mod udviklere og arkitekter, der ønsker at forstå, hvordan Linux- eller Unix-programmer fungerer, og hvordan man strukturerer dem til høj ydeevne.

Linux er et server- operativsystem, og oftest kører dine applikationer netop på dette OS. Selvom jeg siger "Linux", kan du størstedelen af tiden med sikkerhed antage, at der menes alle Unix-lignende operativsystemer generelt. Jeg har dog ikke testet den medfølgende kode på andre systemer. Så hvis du er interesseret i FreeBSD eller OpenBSD, kan resultaterne variere. Når jeg prøver noget, der er specifikt for Linux, angiver jeg det.

Selvom du kan bruge den viden, du får, til at bygge en applikation fra bunden, som vil være fremragende optimeret, er det bedst ikke at gøre det. Hvis du skriver en ny webserver i C eller C++ til din organisations forretningsapplikation, kan det være din sidste dag på jobbet. Men at have kendskab til strukturen af disse applikationer vil hjælpe dig med at vælge mellem allerede eksisterende programmer. Du vil kunne sammenligne systemer baseret på processer med systemer baseret på tråde samt systemer baseret på begivenheder. Du vil forstå og værdsætte, hvorfor Nginx fungerer bedre end Apache httpd, og hvorfor en Python-applikation baseret på Tornado kan betjene flere brugere sammenlignet med en Python-applikation baseret på Django.

ZeroHTTPd: læringsværktøj

ZeroHTTPd — en webserver, som jeg skrev fra bunden i C som et læringsværktøj. Den har ingen eksterne afhængigheder, herunder adgang til Redis. Vi kører vores egne Redis-processer. Læs mere nedenfor.

Selvom vi kunne diskutere teorien længe, er der ikke noget bedre end at skrive noget kode, køre det og sammenligne alle serverarkitekturer. Det er den mest visuelle metode. Derfor vil vi skrive en simpel webserver, ZeroHTTPd, ved at anvende hver model: baseret på processer, tråde og begivenheder. Vi vil teste hver af disse servere og se, hvordan de fungerer i forhold til hinanden. ZeroHTTPd er implementeret i en enkelt C-fil. Serveren baseret på begivenheder inkluderer uthash, en fremragende implementering af en hash-tabel, der leveres i én header-fil. I øvrige tilfælde er der ingen afhængigheder for ikke at komplicere projektet.

Der er mange kommentarer i koden for at hjælpe med forståelsen. Som en simpel webserver med et par linjer kode fungerer ZeroHTTPd også som et minimalt framework for webudvikling. Den har begrænset funktionalitet, men den kan levere statiske filer og meget enkle 'dynamiske' sider. Jeg må sige, at ZeroHTTPd er godt til at lære, hvordan man skaber højtydende Linux-applikationer. Generelt set venter de fleste webtjenester på forespørgsler, kontrollerer dem og behandler dem. Det er præcis, hvad ZeroHTTPd vil gøre. Det er et læringsværktøj, ikke til produktion. Den er ikke stærk i fejlbehandling og vil næppe prale af de bedste sikkerhedspraksisser (åh ja, jeg brugte strcpy) eller med komplicerede tricks i C-sproget. Men jeg håber, det vil klare sin opgave godt.

Hjemmesiden for ZeroHTTPd. Den kan server forskellige filtyper, inklusive billeder.

Gæstebogsapplikation

Moderne webapplikationer er normalt ikke begrænset til statiske filer. De har komplekse interaktioner med forskellige databaser, caches osv. Derfor vil vi skabe en simpel webapplikation kaldet "Gæstebog", hvor besøgende kan efterlade indlæg under deres navne. I gæstebogen gemmes tidligere efterladte indlæg. Der er også en tæller for besøgende nederst på siden.

Webapplikationen "Gæstebog" ZeroHTTPd

Tælleren for besøgende og indlæg i gæstebogen gemmes i Redis. Der er implementeret egne procedurer til kommunikation med Redis, som ikke er afhængige af eksterne biblioteker. Jeg er ikke stor fan af at rulle egen kode ud, når der er offentligt tilgængelige og veldokumenterede løsninger. Men målet med ZeroHTTPd er at undersøge ydeevnen i Linux og adgangen til eksterne tjenester, mens behandling af HTTP-anmodninger har en alvorlig indvirkning på ydeevnen. Vi skal have fuld kontrol over kommunikationen med Redis i hver af vores serverarkitekturer. I en arkitektur bruger vi blokkerende kald, i andre er der procedurer baseret på hændelser. Brug af et eksternt Redis-klientbibliotek vil ikke give den kontrol. Derudover udfører vores lille Redis-klient kun få funktioner (hentning, indstilling og inkrementering af nøgler; hentning og tilføjelse til arrays). Desuden er Redis-protokollen særdeles elegant og enkel. Man behøver endda ikke at lære det specifikt. Faktisk viser det, at hele arbejdet udføres af protokollen i cirka hundrede linjer kode, hvor godt designet det er.

Den følgende illustration viser handlingerne i applikationen, når klienten (browseren) anmoder /guestbookURL.

Mekanismen bag gæstebogsapplikationen

Når der skal vises en side fra gæstebogen, foretages der et kald til filsystemet for at læse skabelonen ind i hukommelsen og tre netværkskald til Redis. Skabelonfilen indeholder det meste af HTML-indholdet til siden på skærmbilledet ovenfor. Der er også specielle pladsholdere til den dynamiske del af indholdet: indlæg og besøgstæller. Vi henter dem fra Redis, indsætter dem på siden og leverer det fuldt udformede indhold til klienten. Det tredje kald til Redis kan undgås, da Redis returnerer den nye værdi af nøglen ved opdatering. Men for vores server med asynkron event-baseret arkitektur er mange netværkskald en god øvelse med hensyn til læring. Derfor forkaster vi den returnerede værdi fra Redis om antallet af besøgende og anmoder om den med et separat kald.

Serverarkitekturer ZeroHTTPd

Vi bygger syv versioner af ZeroHTTPd med ens funktionalitet, men forskellige arkitekturer:

• Iterativ
• Fork server (én dataproces pr. anmodning)
• Pre-fork server (forudgående forking af processer)
• Tråd-server (én tråd pr. anmodning)
• Server med forudoprettede tråde
• Arkitektur baseret på poll()
• Arkitektur baseret på epoll

Vi måler ydeevnen af hver arkitektur ved at belaste serveren med HTTP-anmodninger. Men når man sammenligner arkitekturer med høj parallelisme, øges antallet af anmodninger. Vi tester tre gange og beregner gennemsnittet.

Testmetodologi

Opsætning til belastningstestning af ZeroHTTPd

Det er vigtigt, at alle komponenter ikke kører på én maskine under testene. I dette tilfælde pådrager OS ekstra omkostninger til planlægning, da komponenterne konkurrerer om CPU'en. At måle de operationelle systemomkostninger med hver af de valgte serverarkitekturer er et af de vigtigste mål med denne øvelse. At tilføje flere variabler vil være skadeligt for processen. Derfor fungerer opsætningen på billedet ovenfor bedst.

Hvad gør hver af disse servere

• load.unixism.net: her kører vi ab, Apache Benchmark-værktøjet. Det genererer den belastning, der er nødvendig for at teste vores serverarkitekturer.
• nginx.unixism.net: Nogle gange ønsker vi at køre mere end én instans af serverprogrammet. For dette fungerer Nginx-serveren med de passende indstillinger som en belastningsfordeler for indkommende ab til vores serverprocesser.
• zerohttpd.unixism.net: Her kører vi vores serverprogrammer på syv forskellige arkitekturer, en ad gangen.
• redis.unixism.net: På denne server kører Redis-dæmonen, hvor gæstebogsindlæg og besøgsregistreringer opbevares.

Alle servere kører på en enkelt CPU-kerne. Ideen er at vurdere den maksimale ydeevne for hver af arkitekturerne. Da alle serverprogrammer testes på det samme udstyr, er dette en basislinje for deres sammenligning. Min testopsætning består af virtuelle servere lejet fra Digital Ocean.

Hvad måler vi?

Forskellige metrikker kan måles. Vi vurderer ydeevnen for hver arkitektur i denne konfiguration ved at belaste serverne med anmodninger på forskellige niveauer af parallelisme: belastningen stiger fra 20 til 15.000 samtidige brugere.

Test Results

I det følgende diagram vises servernes ydeevne på forskellige arkitekturer ved forskellige niveauer af parallelisme. På y-aksen er antallet af anmodninger pr. sekund, og på x-aksen er de parallelle forbindelser.

Nedenfor er en tabel med resultaterne.

anmodninger pr. sekund

parallelisme
iterativ
en fork
pre-fork
trådet
pre-threaded
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
stort spredning
2138

5000
–
stort spredning
1600
1100
2519
–
2235

8000
–
–
1200
stort spredning
2451
–
2100

10 000
–
–
stort spredning
–
2200
–
2200

11 000
–
–
–
–
2200
–
2122

12 000
–
–
–
–
970
–
1958

13 000
–
–
–
–
730
–
1897

14 000
–
–
–
–
590
–
1466

15 000
–
–
–
–
532
–
1281

Fra grafen og tabellen kan vi se, at over 8000 samtidige anmodninger har vi kun to spillere tilbage: pre-fork og epoll. Efterhånden som belastningen stiger, præsterer serveren baseret på poll dårligere end den trådede. Arkitekturen med forudlavede tråde udgør en værdig konkurrence mod epoll: dette viser, hvor godt Linux-kernen planlægger et stort antal tråde.

Kildekoden til ZeroHTTPd

Kildekoden til ZeroHTTPd her. For hver arkitektur er der et separat katalog.

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

Udover de syv kataloger til alle arkitekturer er der endnu to i rodkatalogen: public og templates. I den første ligger filen index.html og billedet fra det første skærmbillede. Du kan placere andre filer og mapper der, og ZeroHTTPd skal uden problemer kunne levere disse statiske filer. Hvis stien i browseren svarer til stien i mappen public, så søger ZeroHTTPd i denne katalog efter filen index.html. Indholdet til gæstebogen genereres dynamisk. Den har kun en forside, og dens indhold er baseret på filen ‘templates/guestbook/index.html’. I ZeroHTTPd er det nemt at tilføje dynamiske sider for at udvide funktionaliteten. Ideen er, at brugerne kan tilføje skabeloner i denne katalog og udvide ZeroHTTPd efter behov.

For at bygge alle syv servere, kør make all fra rodkatalogen - og alle builds vil dukke op i denne katalog. De eksekverbare filer søger efter katalogerne public og templates i den katalog, de køres fra.

Linux API

For at forstå informationen i denne artikelcyklus er det ikke nødvendigt at have en dyb forståelse af Linux API. Jeg anbefaler dog at læse mere om emnet, da der findes mange ressourcer online. Selvom vi vil berøre flere kategorier af Linux API, vil vores fokus primært være på processer, tråde, begivenheder og netværksstakken. Udover bøger og artikler om Linux API anbefaler jeg også at læse manualerne for systemopkald og de biblioteksfunktioner, der anvendes.

Ydelse og skalerbarhed

En bemærkning om ydelse og skalerbarhed. Teoretisk set er der ingen forbindelse mellem dem. Du kan have en webservice, der fungerer rigtig godt, med svartider på få millisekunder, men som ikke skalerer overhovedet. På samme måde kan der være en webapplikation, der fungerer dårligt og tager flere sekunder at svare, men som skalerer til at håndtere titusinder af samtidige brugere. Ikke desto mindre er kombinationen af høj ydelse og skalerbarhed en meget kraftfuld kombination. Højtydende applikationer bruger generelt ressourcer sparsomt og kan derfor effektivt betjene flere samtidige brugere på serveren, hvilket reducerer omkostningerne.

CPU- og I/O-opgaver

Endelig er der altid to mulige typer opgaver i beregninger: I/O og CPU. Modtagelse af anmodninger over internettet (netværksind- og uddata), administration af filer (netværks- og diskind- og uddata), kommunikation med databaser (netværks- og diskind- og uddata) – alt dette er I/O-handlinger. Nogle anmodninger til databasen kan belaste CPU'en lidt (sortering, beregning af gennemsnittet af en million resultater osv.). De fleste webapplikationer er begrænset af den maksimalt mulige I/O, mens CPU'en sjældent anvendes fuldt ud. Når du ser, at en eller anden I/O-opgave bruger meget CPU, er det sandsynligvis et tegn på dårlig applikationsarkitektur. Det kan betyde, at CPU-ressourcer bruges på processtyring og kontekstskift – og det er ikke særlig nyttigt. Hvis du laver noget som billedbehandling, konvertering af lydfiler eller maskinlæring, så kræver applikationen kraftige CPU-ressourcer. Men for de fleste applikationer er det ikke tilfældet.

Mere om serverarkitekturer

1. Del I. Iterativ arkitektur
2. Del II. Fork-servere
3. Del III. Pre-fork servere
4. Del IV. Servere med udførelsestråde
5. Del V. Servere med prækompilerede tråde
6. Del VI. Poll-baseret arkitektur
7. Del VII. Epoll-baseret arkitektur

Kilde: habr.com