{"id":35106,"date":"2019-10-31T22:02:22","date_gmt":"2019-10-31T19:02:22","guid":{"rendered":"https:\/\/prohoster.info\/blog\/proizvoditelnost-setevyh-prilozhenij-linux-vvedenie\/"},"modified":"2019-10-31T22:02:22","modified_gmt":"2019-10-31T19:02:22","slug":"proizvoditelnost-setevyh-prilozhenij-linux-vvedenie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/proizvoditelnost-setevyh-prilozhenij-linux-vvedenie","title":{"rendered":"Ydelsen af netv\u00e6rksapplikationer i Linux. Introduktion","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Webapplikationer bruges nu overalt, og blandt alle transportprotokoller udg\u00f8r HTTP st\u00f8rstedelen. N\u00e5r man studerer detaljer i webapplikationsudvikling, bliver operativsystemet, hvor disse applikationer faktisk k\u00f8rer, ofte overset. Opdelingen mellem udvikling (Dev) og drift (Ops) har kun forv\u00e6rret situationen. Men med udbredelsen af DevOps-kulturen begynder udviklerne at p\u00e5tage sig ansvaret for at k\u00f8re deres applikationer i skyen, s\u00e5 det er meget nyttigt for dem at blive grundigt bekendt med backend'en i operativsystemet. Dette er is\u00e6r nyttigt, hvis du fors\u00f8ger at implementere et system til tusindvis eller titusindvis af samtidige forbindelser.<\/p>\n

Begr\u00e6nsningerne i webtjenester ligner meget dem i andre applikationer. Uanset om det er belastningsbalance eller databaser, har alle disse applikationer lignende problemer i h\u00f8jtydende milj\u00f8er. At forst\u00e5 disse grundl\u00e6ggende begr\u00e6nsninger og m\u00e5der at overvinde dem p\u00e5 vil generelt tillade dig at vurdere ydeevnen og skalerbarheden af dine webapplikationer.<\/p>\n

Jeg skriver denne serie artikler som svar p\u00e5 sp\u00f8rgsm\u00e5l fra unge udviklere, der \u00f8nsker at blive velbevandrede systemarkitekter. Det er umuligt at forst\u00e5 metoderne til optimering af Linux-applikationer uden at dykke ned i det grundl\u00e6ggende, og hvordan de fungerer p\u00e5 operativsystemniveau. Selvom der findes mange typer applikationer, vil jeg i denne cyklus unders\u00f8ge netv\u00e6rksapplikationer og ikke desktop-applikationer som browsere eller tekstbehandlere. Dette materiale er rettet mod udviklere og arkitekter, der \u00f8nsker at forst\u00e5, hvordan Linux- eller Unix-programmer fungerer, og hvordan man strukturerer dem til h\u00f8j ydeevne.
\n<\/a><\/noindex>
\nLinux er et server-<\/i> operativsystem, og oftest k\u00f8rer dine applikationer netop p\u00e5 dette OS. Selvom jeg siger \"Linux\", kan du st\u00f8rstedelen af tiden med sikkerhed antage, at der menes alle Unix-lignende operativsystemer generelt. Jeg har dog ikke testet den medf\u00f8lgende kode p\u00e5 andre systemer. S\u00e5 hvis du er interesseret i FreeBSD eller OpenBSD, kan resultaterne variere. N\u00e5r jeg pr\u00f8ver noget, der er specifikt for Linux, angiver jeg det.<\/p>\n

Selvom du kan bruge den viden, du f\u00e5r, til at bygge en applikation fra bunden, som vil v\u00e6re fremragende optimeret, er det bedst ikke at g\u00f8re det. Hvis du skriver en ny webserver i C eller C++ til din organisations forretningsapplikation, kan det v\u00e6re din sidste dag p\u00e5 jobbet. Men at have kendskab til strukturen af disse applikationer vil hj\u00e6lpe dig med at v\u00e6lge mellem allerede eksisterende programmer. Du vil kunne sammenligne systemer baseret p\u00e5 processer med systemer baseret p\u00e5 tr\u00e5de samt systemer baseret p\u00e5 begivenheder. Du vil forst\u00e5 og v\u00e6rds\u00e6tte, hvorfor Nginx fungerer bedre end Apache httpd, og hvorfor en Python-applikation baseret p\u00e5 Tornado kan betjene flere brugere sammenlignet med en Python-applikation baseret p\u00e5 Django.<\/p>\n

ZeroHTTPd: l\u00e6ringsv\u00e6rkt\u00f8j<\/h1>\n

\nZeroHTTPd<\/a><\/noindex>\u00a0\u2014 en webserver, som jeg skrev fra bunden i C som et l\u00e6ringsv\u00e6rkt\u00f8j. Den har ingen eksterne afh\u00e6ngigheder, herunder adgang til Redis. Vi k\u00f8rer vores egne Redis-processer. L\u00e6s mere nedenfor.<\/p>\n

Selvom vi kunne diskutere teorien l\u00e6nge, er der ikke noget bedre end at skrive noget kode, k\u00f8re 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\u00e5 processer, tr\u00e5de 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\u00e5 begivenheder inkluderer uthash<\/a><\/noindex>, en fremragende implementering af en hash-tabel, der leveres i \u00e9n header-fil. I \u00f8vrige tilf\u00e6lde er der ingen afh\u00e6ngigheder for ikke at komplicere projektet.<\/p>\n

Der er mange kommentarer i koden for at hj\u00e6lpe med forst\u00e5elsen. Som en simpel webserver med et par linjer kode fungerer ZeroHTTPd ogs\u00e5 som et minimalt framework for webudvikling. Den har begr\u00e6nset funktionalitet, men den kan levere statiske filer og meget enkle 'dynamiske' sider. Jeg m\u00e5 sige, at ZeroHTTPd er godt til at l\u00e6re, hvordan man skaber h\u00f8jtydende Linux-applikationer. Generelt set venter de fleste webtjenester p\u00e5 foresp\u00f8rgsler, kontrollerer dem og behandler dem. Det er pr\u00e6cis, hvad ZeroHTTPd vil g\u00f8re. Det er et l\u00e6ringsv\u00e6rkt\u00f8j, ikke til produktion. Den er ikke st\u00e6rk i fejlbehandling og vil n\u00e6ppe prale af de bedste sikkerhedspraksisser (\u00e5h ja, jeg brugte strcpy<\/code>) eller med komplicerede tricks i C-sproget. Men jeg h\u00e5ber, det vil klare sin opgave godt.<\/p>\n

\"Ydelsen
\nHjemmesiden for ZeroHTTPd. Den kan server forskellige filtyper, inklusive billeder.<\/i><\/p>\n

G\u00e6stebogsapplikation<\/h1>\n

\nModerne webapplikationer er normalt ikke begr\u00e6nset til statiske filer. De har komplekse interaktioner med forskellige databaser, caches osv. Derfor vil vi skabe en simpel webapplikation kaldet \"G\u00e6stebog\", hvor bes\u00f8gende kan efterlade indl\u00e6g under deres navne. I g\u00e6stebogen gemmes tidligere efterladte indl\u00e6g. Der er ogs\u00e5 en t\u00e6ller for bes\u00f8gende nederst p\u00e5 siden.<\/p>\n

\"Ydelsen
\nWebapplikationen \"G\u00e6stebog\" ZeroHTTPd<\/i><\/p>\n

T\u00e6lleren for bes\u00f8gende og indl\u00e6g i g\u00e6stebogen gemmes i Redis. Der er implementeret egne procedurer til kommunikation med Redis, som ikke er afh\u00e6ngige af eksterne biblioteker. Jeg er ikke stor fan af at rulle egen kode ud, n\u00e5r der er offentligt tilg\u00e6ngelige og veldokumenterede l\u00f8sninger. Men m\u00e5let med ZeroHTTPd er at unders\u00f8ge ydeevnen i Linux og adgangen til eksterne tjenester, mens behandling af HTTP-anmodninger har en alvorlig indvirkning p\u00e5 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\u00e5 h\u00e6ndelser. Brug af et eksternt Redis-klientbibliotek vil ikke give den kontrol. Derudover udf\u00f8rer vores lille Redis-klient kun f\u00e5 funktioner (hentning, indstilling og inkrementering af n\u00f8gler; hentning og tilf\u00f8jelse til arrays). Desuden er Redis-protokollen s\u00e6rdeles elegant og enkel. Man beh\u00f8ver endda ikke at l\u00e6re det specifikt. Faktisk viser det, at hele arbejdet udf\u00f8res af protokollen i cirka hundrede linjer kode, hvor godt designet det er.<\/p>\n

Den f\u00f8lgende illustration viser handlingerne i applikationen, n\u00e5r klienten (browseren) anmoder \/guestbookURL<\/code>.<\/p>\n

\"Ydelsen
\nMekanismen bag g\u00e6stebogsapplikationen<\/i><\/p>\n

N\u00e5r der skal vises en side fra g\u00e6stebogen, foretages der et kald til filsystemet for at l\u00e6se skabelonen ind i hukommelsen og tre netv\u00e6rkskald til Redis. Skabelonfilen indeholder det meste af HTML-indholdet til siden p\u00e5 sk\u00e6rmbilledet ovenfor. Der er ogs\u00e5 specielle pladsholdere til den dynamiske del af indholdet: indl\u00e6g og bes\u00f8gst\u00e6ller. Vi henter dem fra Redis, inds\u00e6tter dem p\u00e5 siden og leverer det fuldt udformede indhold til klienten. Det tredje kald til Redis kan undg\u00e5s, da Redis returnerer den nye v\u00e6rdi af n\u00f8glen ved opdatering. Men for vores server med asynkron event-baseret arkitektur er mange netv\u00e6rkskald en god \u00f8velse med hensyn til l\u00e6ring. Derfor forkaster vi den returnerede v\u00e6rdi fra Redis om antallet af bes\u00f8gende og anmoder om den med et separat kald.<\/p>\n

Serverarkitekturer ZeroHTTPd<\/h1>\n

\nVi bygger syv versioner af ZeroHTTPd med ens funktionalitet, men forskellige arkitekturer:<\/p>\n