Webapplikasjoner brukes nå overalt, og blant alle transportprotokoller utgjør HTTP en stor del. Når man utforsker detaljene ved utvikling av webapplikasjoner, legger de fleste svært lite vekt på operativsystemet der disse applikasjonene faktisk kjører. Delingen av utvikling (Dev) og drift (Ops) har bare forverret situasjonen. Men med spredningen av DevOps-kulturen begynner utviklerne å ta ansvar for å kjøre sine applikasjoner i skyen, så det er svært nyttig for dem å bli godt kjent med backend-operativsystemet. Dette er spesielt nyttig hvis du prøver å distribuere et system for tusenvis eller titusenvis av samtidige tilkoblinger.

Begrensninger i webtjenester ligner veldig på begrensninger i andre applikasjoner. Enten det er lastbalanserere eller databaser, har alle disse applikasjonene lignende utfordringer i høyytelsesmiljøet. Å forstå disse grunnleggende begrensningene og måtene å omgå dem på, vil generelt gjøre det lettere å evaluere ytelsen og skalerbarheten til webapplikasjonene dine.

Jeg skriver denne serien med artikler som svar på spørsmål fra unge utviklere som ønsker å bli godt informerte systemarkitekter. Det er umulig å forstå metodene for optimalisering av Linux-applikasjoner klart uten å dykke ned i grunnleggende prinsipper for hvordan de fungerer på operativsystemnivå. Selv om det finnes mange typer applikasjoner, ønsker jeg å utforske nettverksapplikasjoner i denne syklusen, ikke skrivebordsapplikasjoner som nettlesere eller tekstredigerere. Dette materialet er rettet mot utviklere og arkitekter som ønsker å forstå hvordan programmer på Linux eller Unix fungerer og hvordan de kan struktureres for høy ytelse.

Linux er et server operativsystem, og oftest kjører applikasjonene dine på dette OS-et. Selv om jeg sier «Linux», kan du stort sett med trygghet anta at jeg refererer til alle Unix-lignende operativsystemer generelt. Likevel har jeg ikke testet den medfølgende koden på andre systemer. Så hvis du er interessert i FreeBSD eller OpenBSD, kan resultatet variere. Når jeg prøver noe spesifikt for Linux, vil jeg påpeke dette.

Selv om du kan bruke den tilegnede kunnskapen til å lage en applikasjon fra bunnen av, og den vil være strålende optimalisert, er det best å ikke gjøre det. Hvis du skriver en ny webserver i C eller C++ for forretningsapplikasjonen til organisasjonen din, kan det være din siste dag på jobben. Men kunnskap om strukturen til disse applikasjonene vil hjelpe deg å velge eksisterende programmer. Du vil kunne sammenligne systemer basert på prosesser med systemer basert på tråder, samt basert på hendelser. Du vil forstå og vurdere hvorfor Nginx fungerer bedre enn Apache httpd, samt hvorfor en Python-applikasjon basert på Tornado kan betjene flere brukere sammenlignet med en Python-applikasjon basert på Django.

ZeroHTTPd: læringsverktøy

ZeroHTTPd — en webserver som jeg skrev fra bunnen av i C som et læringsverktøy. Den har ingen eksterne avhengigheter, inkludert tilgang til Redis. Vi kjører våre egne Redis-prosedyrer. Se mer nedenfor.

Selv om vi kunne diskutere teorien i lang tid, er det ingenting bedre enn å skrive kode, kjøre den og sammenligne de ulike serverarkitekturene. Dette er den mest illustrative metoden. Derfor skal vi skrive en enkel webserver, ZeroHTTPd, og bruke hver modell: basert på prosesser, tråder og hendelser. Vi vil teste hver av disse serverne og se hvordan de fungerer sammenlignet med hverandre. ZeroHTTPd implementeres i én C-fil. Serveren basert på hendelser inkluderer uthash, en utmerket implementering av en hashtabell som leveres i én header-fil. Ellers er det ingen avhengigheter for å unngå å komplisere prosjektet.

Koden har mange kommentarer for å hjelpe med forståelsen. Som en enkel webserver med noen få linjer kode fungerer ZeroHTTPd også som et minimalt rammeverk for webutvikling. Den har begrenset funksjonalitet, men kan levere statiske filer og veldig enkle «dynamiske» sider. Jeg må si at ZeroHTTPd er godt egnet for å lære hvordan man lager høyytelses Linux-applikasjoner. I bunn og grunn venter de fleste webtjenester på forespørslene, sjekker dem og behandler dem. Det er nettopp det ZeroHTTPd vil gjøre. Det er et læringsverktøy, ikke for produksjon. Den er ikke sterk på feilhåndtering og kan knapt skryte av beste sikkerhetspraksis (å ja, jeg brukte strcpy) eller med småspråkelige triks av C-språket. Men jeg håper det vil gjøre oppgaven sin godt.

Forside for ZeroHTTPd. Den kan levere forskjellige filtyper, inkludert bilder.

Gjestebok-applikasjonen

Moderne webapplikasjoner er vanligvis ikke begrenset til statiske filer. De har kompliserte interaksjoner med forskjellige databaser, cacher, etc. Derfor vil vi lage en enkel webapplikasjon kalt «Gjestebok», hvor besøkende kan legge igjen meldinger med navnet sitt. I gjesteboken lagres tidligere meldinger. Det finnes også en besøksteller nederst på siden.

Webapplikasjonen «Gjestebok» ZeroHTTPd

Besøkstelleren og meldinger fra gjesteboken lagres i Redis. For kommunikasjon med Redis er det implementert egne prosedyrer som ikke er avhengige av eksterne biblioteker. Jeg er ikke en stor fan av å utvikle egen kode når det finnes offentlige og godt testede løsninger. Men målet med ZeroHTTPd er å utforske ytelsen til Linux og tilgangen til eksterne tjenester, mens håndtering av HTTP-forespørselene alvorlig påvirker ytelsen. Vi må ha full kontroll over kommunikasjonen med Redis i hver av våre serverarkitekturer. I en arkitektur bruker vi blokkerende kall, i andre - hendelsesbaserte prosedyrer. Bruken av et eksternt klientbibliotek for Redis vil ikke gi en slik kontroll. I tillegg utfører vår lille Redis-klient bare et par funksjoner (hente, sette og inkrementere en nøkkel; hente og legge til i en array). Dessuten er protokollen til Redis eksepsjonelt elegant og enkel. Den trenger ikke spesiell opplæring. Det faktum at hele arbeidet protokollen gjør, kan utføres på omtrent hundre linjer med kode, sier noe om hvor godt det er gjennomtenkt.

I det følgende bildet vises aktiviteter i applikasjonen når klienten (nettleseren) sender en forespørsel. /guestbookURL.

Mekanismen for drift av gjestebok-applikasjonen

Når en side for gjesteboken skal genereres, skjer det ett kall til filsystemet for å lese malen inn i minnet, og tre nettverkskall til Redis. Malfilen inneholder mesteparten av HTML-innholdet for siden på skjermbildet over. Det finnes også spesielle plassholdere for den dynamiske delen av innholdet: innlegg og besøkstelleren. Vi henter dem fra Redis, setter dem inn på siden og leverer kunden det fullstendig formede innholdet. Det tredje kallet til Redis kan unngås, siden Redis returnerer en ny verdi for nøkkelen når den økes. Imidlertid, for vår server med en asynkron arkitektur basert på hendelser, er mange nettverkskall en god trening i læringsøyemed. Dermed slipper vi den returnerte verdien fra Redis om antall besøkende og ber om den med et eget kall.

Serverarkitekturer ZeroHTTPd

Vi bygger syv versjoner av ZeroHTTPd med identisk funksjonalitet, men forskjellige arkitekturer:

• Iterativ
• Fork-server (ett dataprogramprosess per forespørsel)
• Pre-fork server (forhåndsforgrening av prosesser)
• Server med tråder (en tråd per forespørsel)
• Server med forhåndsskaping av tråder
• Arkitektur basert på poll()
• Arkitektur basert på epoll

Vi måler ytelsen til hver arkitektur ved å belaste serveren med HTTP-forespørsel. Men når man sammenligner arkitekturer med høy grad av parallellisme, øker antallet forespørsel. Vi tester tre ganger og regner ut gjennomsnittet.

Testmetodologi

Oppsett for belastningstest av ZeroHTTPd

Det er viktig at ikke alle komponenter kjører på én maskin når testene utføres. I så fall påfører operativsystemet ekstra kostnader for planlegging, ettersom komponentene konkurrerer om CPU-en. Å måle operativsystemets overhead med hver av de valgte serverarkitekturene er et av de viktigste målene med dette øvelsen. Å legge til flere variabler vil være skadelig for prosessen. Derfor fungerer oppsettet på bildet over best.

Hva gjør hver av disse serverne

• load.unixism.net: her kjører vi ab, Apache Benchmark-verktøyet. Det genererer belastningen som kreves for å teste våre serverarkitekturer.
• nginx.unixism.net: noen ganger ønsker vi å kjøre mer enn én instans av serverprogrammet. For dette fungerer Nginx-serveren med de riktige innstillingene som en belastningsfordeler som mottar ab til våre serverprosesser.
• zerohttpd.unixism.net: her kjører vi programmene våre på syv ulike arkitekturer, én av gangen.
• redis.unixism.net: på denne serveren kjører Redis-daemonen, der oppføringene i gjesteboken og besøksstatistikken lagres.

Alle servere kjører på ett prosessorkjerne. Ideen er å vurdere den maksimale ytelsen til hver arkitektur. Siden alle serverprogrammer blir testet på det samme utstyret, er dette et basisnivå for sammenligning. Min testoppsett består av virtuelle servere leid fra Digital Ocean.

Hva måler vi?

Vi kan måle ulike indikatorer. Vi evaluerer ytelsen til hver arkitektur i denne konfigurasjonen, ved å laste serverne med forespørselene på forskjellige nivåer av parallellisme: belastningen øker fra 20 til 15 000 samtidige brukere.

Testresultater

I diagrammet nedenfor vises ytelsen til serverne på forskjellige arkitekturer ved forskjellige nivåer av parallellisme. På y-aksen er antall forespørseler per sekund, på x-aksen er parallelle tilkoblinger.

Under er tabellen med resultatene.

forespørseler per sekund

parallellisme
iterativ
fork
pre-fork
tråd-basert
pre-tråd-basert
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
stor spredning
2138

5000
–
stor spredning
1600
1100
2519
–
2235

8000
–
–
1200
stor spredning
2451
–
2100

10 000
–
–
stor 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 forespørseler er det bare to aktører igjen: pre-fork og epoll. Med økende belastning fungerer serveren basert på poll dårligere enn den tråd-baserte. Arkitekturen med forhåndsopprettede tråder gir en solid konkurranse til epoll: dette vitner om hvor godt Linux-kjernen planlegger et stort antall tråder.

Kildekode for ZeroHTTPd

Kildekode for ZeroHTTPd her. For hver arkitektur er det en egen 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

I tillegg til de syv katalogene for alle arkitekturer, finnes det to andre i rotkatalogen: public og templates. I den første ligger filen index.html og bildet fra det første skjermbildet. Du kan plassere andre filer og mapper der, og ZeroHTTPd bør uten problemer servere disse statiske filene. Hvis stien i nettleseren samsvarer med stien i public-mappen, vil ZeroHTTPd søke etter filen index.html i denne katalogen. Innholdet til gjesteboken genereres dynamisk. Det har bare en hovedside, og dens innhold er basert på filen 'templates/guestbook/index.html'. Det er enkelt å legge til dynamiske sider i ZeroHTTPd for utvidelse. Ideen er at brukere kan legge til maler i denne katalogen og utvide ZeroHTTPd etter behov.

For å bygge alle de syv serverne, kjør make all fra rotkatalogen - og alle byggefilene vil dukke opp i denne katalogen. Kjørbare filer leter etter katalogene public og templates i den katalogen de kjøres fra.

Linux API

For å forstå informasjonen i denne artikkelserien, trenger du ikke å ha en god forståelse av Linux API. Jeg anbefaler imidlertid å lese mer om emnet; det finnes mange referanser på nettet. Selv om vi vil berøre flere kategorier av Linux API, vil vårt fokus hovedsakelig være på prosesser, tråder, hendelser og nettverksstabler. I tillegg til bøker og artikler om Linux API, anbefaler jeg også å lese man-sider for systemkall og brukte biblioteksfunksjoner.

Ytelse og skalerbarhet

En kommentar om ytelse og skalerbarhet. Teoretisk sett er det ingen sammenheng mellom dem. Du kan ha en webtjeneste som fungerer veldig bra, med responstider på noen millisekunder, men som ikke skaleres i det hele tatt. På samme måte kan det være en dårlig fungerende webapplikasjon som tar flere sekunder å svare, men som skalerer til titalls for å håndtere titusener av samtidige brukere. Likevel er kombinasjonen av høy ytelse og skalerbarhet en veldig kraftig kombinasjon. Høyytelsesapplikasjoner bruker generelt ressurser økonomisk og betjener dermed flere samtidige brukere på serveren, noe som reduserer kostnadene.

CPU- og I/O-oppgaver

Til slutt, i beregningene finnes det alltid to mulige typer oppgaver: for I/O og CPU. Håndtering av forespørslene via internett (nettverksinngang/utgang), filbearbeiding (nettverks og disk I/O), kommunikasjon med databasen (nettverks og disk I/O) – alt dette er I/O-oppgaver. Enkelte forespørsel til databasen kan belaste CPU en smule (sortering, beregning av gjennomsnittet av millioner av resultater, osv.). De fleste webapplikasjoner er begrenset av det maksimalt mulige I/O, mens prosessoren sjeldent brukes til sin fulle kapasitet. Når du ser at en eller annen oppgave for inngang/utgang bruker mye CPU, er det mest sannsynlig et tegn på dårlig applikasjonsarkitektur. Dette kan bety at CPU-ressursene brukes til prosesshåndtering og kontekstbytter - og det er ikke helt nyttig. Hvis du gjør noe som bildebehandling, konvertering av lydfiler eller maskinlæring, vil applikasjonen kreve kraftige CPU-ressurser. Men for de fleste applikasjoner er det ikke tilfelle.

Mer om serverarkitekturer

1. Del I. Iterativ arkitektur
2. Del II. Fork-servere
3. Del III. Pre-fork servere
4. Del IV. Servere med tråder
5. Del V. Servere med forhåndsskapt tråder
6. Del VI. Arkitektur basert på poll
7. Del VII. Arkitektur basert på epoll

Kilde: habr.com