Nginx vs Apache: Webserver opgør

Internettet, som vi kender det i dag, startede sin globale “erobring” i 90’erne. Hele “Web” -protokollen kan opsummeres som en besøgende, der anmoder om et dokument fra en given webadresse, med DNS- og IP-system, der videresender denne anmodning til den rigtige computer. Denne computer, der er vært for den ønskede webside, “serverer” websiden tilbage til den besøgende.

Websider er i det væsentlige HTML-dokumenter. For at kunne betjene forskellige websider til de besøgende, har “servering” -maskinen behov for et serverprogram. Software som Nginx vs Apache håndterer anmodninger, analyserer dem og afleverer derefter de tilsvarende dokumenter, der skal vises i en besøgendes browser.

Apache

Vi dykker ind i Apache først, da det var den første til at blive udgivet.

Efter Tim Berners-Lees CERN httpd og NCSA HTTPd i de første par år af internettet, erobrede Apache – først udgivet i 1995 – hurtigt markedet og blev verdens mest populære webserver. I dag er det stadig i denne markedsposition, men hovedsageligt af ældre grunde. Apache udvikles og vedligeholdes af Apache Foundation under Apache-licensen.

Der er to forskellige historier om, hvordan Apache fik sit navn. Den ene version siger, at navnet stammer fra den berømte indianerarv, mens den anden siger, at navnet er en ordspil på “en ujævn server”, der fulgte efter en række software lappeløsninger.

Linux

Apaches enorme markedsandel skyldes delvis det faktum, at det leveres forudinstalleret med alle større Linux-distributioner, som Red Hat / Centos og Ubuntu.

Et eksempel på den vigtige rolle, Apache spiller i Linux-verdenen, er, at dens server-procesnavn er HTTPd, hvilket gør Apache til et synonym med webserver-software.

Ud over at være den første seriøse spiller på webservermarkedet, skyldes en del af Apaches spredning sin konfigurationssystem og dens .htaccess-fil.

.htaccess

Apache bruger .htaccess til dens konfiguration. Der er masser af tutorials om, hvordan man konfigurerer, redigerer og arbejder med denne fil, da den giver en masse fleksibilitet i at konfigurere, hvordan Apache håndterer indgående anmodninger. Nogle eksempler er: forskellige omdirigeringsregler, maksimale upload-filstørrelser, URL-omskrivninger, memory limits, biblioteksbeskyttelse (htpasswd), expires headers, cache-control headers, encoding headers, cookies, query string manipulation.

På den anden side bruger Kinsta Nginx, som ikke understøtter .htaccess-filer. Indstillinger og regler fra dine .htaccess-filer kan imidlertid let “oversættes” til Nginx ‘egen syntaks om omskrivningsregel.

En af de vigtigste “Fordele” for Apache er, at i server root – hovedwebstedets bibliotek – kan hvert niveau eller bibliotek i katalog-træet have sin egen .htaccess-fil med sin egen konfiguration.

For delte hostingudbydere er dette en drøm, fordi de kan give hundreder af brugere på den samme maskine en måde at konfigurere, hvordan deres websteder serveres, uden at det påvirker de andre. Kunder kan konfigurere en masse detaljer i et begrænset delt hosting-miljø, mens de aldrig rører ved den globale serverkonfiguration.

Som den officielle dokumentation siger:

“Generelt skal du kun bruge .htaccess-filer, når du ikke har adgang til hovedserver-konfigurationsfilen.”

Denne fleksibilitet kommer imidlertid på bekostning af ydelsen “tillader .htaccess-filer forårsager et performance hit, uanset om du endda rent faktisk bruger dem!”

Hver gang .htaccess-filer er aktiveret, skal Apache gennemgå hele katalogtræet fra den anmodede URL eller fil gennem alle de højere niveauer, indtil serverens root-katalog og derefter indlæse dem, for hver anmodning. Den skal derefter behandle disse filer og konfigurere sig selv til hver af de mapper, der er konfigureret på denne måde.

Med WordPress-websteder kan tingene blive rigtig komplekse. Et typisk WordPress-websted kan have hundreder af anmodninger fra forskellige mapper.

Fra en /wp-content/uploads/yyyy/mm type dirs vil det typisk have flere anmodninger om en enkelt sidebelastning, ofte danner forskellige månedlige mapper. Derefter vil der være /wp-content/themes/parent-theme static resources, /wp-content/themes/child-theme underordnede ressourcer: disse vil omfatte javascript, css-filer, billeder.

Derefter vil der også være /wp-content/plugins med statiske filer indlæst fra ofte snesevis af plugin-undermapper. For hver af disse ressourcer er Apache nødt til at krydse hele træet for at se efter konfigurationen.

En analyse har vist, at en typisk WordPress-opsætning, temmelig almindelig for websteder på delte værter, vil omfatte 42 separate .htaccess executions og 249 separate udseende til .htaccess-filen.

Dette er bare på et webserverniveau. Besøgende skal stadig vente på, at PHP-processen udfører hele WordPress-opkaldsstakken for at oprette databaseforespørgslen og give den til MySQL for at samle websiden og sende den til den besøgende.

Moduler

En anden ting, der gjorde Apache populær er dets dynamiske modulsystem.

Moduler – som en funktion, der giver brugerne mulighed for at udvide webserver-funktionaliteten – findes både i Nginx og Apache. Apache giver brugerne mulighed for at installere moduler, når webserveren allerede er installeret og distribueret og derefter aktiveret / deaktiveret dem efter behov. Debian-baserede distributioner har kommandoer, der tillader aktivering og deaktivering af disse moduler uden at skulle redigere nogen konfigurationsfiler: a2enmod og a2dismod.

Den officielle liste over moduler, der kommer som en del af Apache-standarddistribution er her, og disse inkluderer ting fra komprimering, kryptering, logging, omdirigeringer til mere avancerede ting som redigeringsanmodninger og svar med avanceret syntaks.

Nginx

Nginx (også kendt som nginx eller NGINX) kom på scenen i 2004, da det først blev offentliggjort af den russiske udvikler Igor Sysoev. Som Owen Garrett, Nginx ‘projektleder sagde:

”Nginx blev skrevet specifikt for at tackle Apache-webservernes ydelses begrænsninger.”

Serveren blev først oprettet som et skaleringsværktøj til webstedet rambler.ru i 2002. Den findes i to versioner: open source, med BSD-type licens, og Nginx Plus, med support og yderligere virksomhedsfunktioner.

Efter at den blev frigivet, blev Nginx hovedsageligt brugt til at betjene statiske filer og som en load-balancer eller reverse proxy foran Apache-installationer. Efterhånden som internettet udviklede sig, og behovet for at klemme hver sidste dråbe hastighed og hardware-effektivitet med det, begyndte flere websteder at erstatte Apache med Nginx helt, takket være en mere moden software.

I marts 2019 blev Nginx Inc købt af F5 Networks for 670 millioner USD. I det øjeblik, som Techcrunch rapporterer, havde Nginx-serveren ”375 millioner websteder med ca. 1.500 betalende kunder”.

Ifølge data fra w3techs er Nginx markedsandel vokset støt, presset Apache ud og nedbrudt fra første omgang:

Disse data vedrører overordnede webservere globalt, men hvis vi tager en prøve på de øverste en million websteder, har Nginx været der i noget tid nu:

Google-søgetendenser synes også at afspejle denne kendsgerning:

Netcraft-undersøgelse antyder, at Apache er blevet overhalet af Nginx i april 2019.

Nginx-konfiguration

Nginx har ikke et konfigurationssystem som Apache, så selv om det er meget mere effektivt og hurtigt, er det ikke bredt ansat hos udbydere af detailhosting. Det skinner ikke i delte miljøer, som Apache gør.

På den anden side får Nginx, som vi sagde, ikke tilladelse af funktioner på katalogniveau en betydelig fordel i forhold til Apache. Der er en artikel på Nginx-wiki, der sammenligner effektpåvirkningen:

Nginx moduler

Nginx-modulsystem er endnu en ting, der positionerer det som et mere premium valg. Nginx-moduler skal typisk aktiveres på bygningstidspunktet, hvilket betyder, at en mere teknisk dygtighed er involveret, og tilføjelsen af ​​moduler efter installationen er lidt mere kompliceret.

I 2016 med version 1.9.11 er tingene ændret, og det officielle / verificerede depot for dynamiske moduler er forbeholdt de betalende brugere. Fra maj 2019 meddelte de, at de starter udviklingen af ​​support til QUIC og HTTP / 3.

Sagen om cache: Nginx vs Apache

Caching – hvis vi ønsker at forenkle det – kan afbildes som at forberede indholdet til besøgende på webstedet, før de besøger, så når de “banker på døren”, behøver du ikke at kigge efter det indhold, de leder efter . Du har allerede forberedt det, og du overleverer det til dem uden nogen ventetid.

Ligesom Apache, plejede Nginx ‘typiske opsætning at sidde mellem servere og slutbruger for at lindre ydeevne på resten af ​​infrastrukturen. I disse tilfælde kan det cache statisk indhold uden behov for at hente det fra den beskyttede originalserver hver gang.

Hvis vi bruger Nginx som en enkeltstående webserver – som det er tilfældet med Kinsta LXC-containere – er der ikke et sådant behov. Nginx er meget effektiv til at servere statisk indhold alene.

Så er der spørgsmålet om dynamisk cache eller sidecache. I et WordPress-websteds scenarie betyder dette at gemme alle WordPress-sider, der er genereret til hver URL i hukommelsen eller på disken.

FastCGI-caching er naturligt tilgængelig i en standard Nginx-installation. Det er enkelt, meget kraftfuldt og en af ​​de mindre almindeligt anvendte Nginx-funktioner.

For at sammenligne dette med Apache-ækvivalenter, skal du vide, at Apache har mod_cache-modul, der angiveligt har en tendens til at være uklar, og er i konflikt med andre moduler. Så standard cache-løsningen, der er implementeret med Apache, er Varnish HTTP-accelerator. Selvom Varnish er den dedikerede industriløsning, giver nogle nylige tests Nginx-cachen en klar kant over lakken.

Hos Kinsta bruger vi Nginx til dynamisk WordPress-caching sammen med et proprietært cache-plugin, der tillader granuleret kontrol over cachelagrede sider, og statiske aktiver, der er cache af Kinsta CDN.

Håndteringsanmodninger: Nginx vs Apache

Den største forskel mellem Apache og Nginx er i den underliggende arkitektur af den måde, de håndterer anmodninger på.

Apache behandler anmodninger med MPM-moduler eller Multi-Processing-moduler, som er “ansvarlig for at binde til netværksporte på maskinen, acceptere anmodninger og sende children til at håndtere anmodningerne.”

Den ældste MPM, der stammer helt tilbage til Apaches begyndelse, er prefork-modul. Dette modul alene kan krediteres for Apache’ dårlige omdømme. I denne tilstand spawn Apache ny proces med en tråd på hver anmodning.

Dette modul, brugt med mod_php, betød, at Apache-serveren integrerede en PHP-tolk i hver eneste proces, selvom den skulle tjene CSS-filer eller billeder.

Dette var ineffektivt. Prefork-modul leveres med Apache som standardmodul. Det begrænser også forbindelser til HTTP / 1.

I senere år har Apache udviklet multetrådede worker-mpm, og derefter, event mpm. Begge af dem lindrer mange af Apaches performanceproblemer. Skift til php-fpm gør det muligt for Apache at stadig være en konkurrerende løsning i dag sammen med at eliminere brugen af ​​.htaccess, men den slags besejrer dens formål.

Nginx bruger asynkron, ikke-blokerende begivenhedsstyret arkitektur.

For at forklare forskellen: i Linux / Unix-verdenen kører processer programmer.

Tråde er en undergruppe af processer, og der kan være flere tråde inden for en procesudførelse. Tænk på dette som flere faner i et browservindue. På denne måde kan et program udnytte flere CPU-er og multi-core, multi-thread CPU’er for at udføre hurtigere. Du kan læse Linus Torvalds uddybe forskellene.

Kort sagt, Apache bruger processer til enhver forbindelse (og med arbejder mpm bruger den tråde). Når trafikken stiger, bliver den hurtigt for dyr.

Vi kan forestille os en ny proces- eller trådoprettelse som opstart af en computer eller opstart af programmer. Selv på det hurtigste af computere tager det stadig nogen tid. Når websteder i dag fremsætter hundreder af anmodninger om en enkelt sides belastning, tilføjes dette hurtigt.

Event mpm går lidt længere med hensyn til optimering, men nogle test viser, at det ikke kan overskride Nginx. Især når vi taler om statiske filer, hvor Nginx tjener så meget som det dobbelte af de anmodninger, som Apache gør.

Nginx har ideelt en arbejdstagerproces pr. CPU / kerne. Forskellen mellem Nginx-arbejdsprocesser er, at hver enkelt kan håndtere hundretusinder af indkommende netværksforbindelser pr. arbejdstager. Der er ikke behov for at oprette nye tråde eller processer til hver forbindelse.

Dette er grunden til, at større Content Delivery Networks, som Cloudflare, MaxCDN, og vores partner KeyCDN – eller websteder som Netflix – finder Nginx afgørende for deres indholdslevering.

Listen over virksomheder, der drager fordel af Nginx, er for lang til at liste dem alle, så vi slutter med Automattic, det private firma bag WordPress.com.

Automattic konverterede alle deres load-balancere til Nginx til WordPress.com i 2008 (du kan læse om det her) og migrerede deres server stack fuldstændigt til Nginx.

Kontrollere det i det virkelige liv

Hvis vi vil undersøge, hvad webstedet i produktionen bruger, kan vi normalt finde dette i HTTP-svaroverskrifterne. Dette betyder, at vi bliver nødt til at højreklikke på et websted> Inspect i udviklerværktøjerne, vi vil vælge netværkspanelet og derefter genindlæse webstedet. Vi ser alle de ressourcer, webstedet indlæser. Hvis vi vælger en bestemt ressource og dens fane Headers, ser vi normalt serverinformationen. Hvis webstedet bruger CDN, kan vi muligvis se noget som Cloudflare på serverlinjen eller noget i retning af Varnish, hvis webstedet bruger HTTP-accelerator.

Dette er et eksempel på et WordPress-websted, der bruger en typisk delt hostingopsætning med cPanel, Apache og PHP:

Dette er en webside på Nginx:

Hvis vi udvider den på venstre side, vil vi også kunne analysere tiden for hver ressource og se dens indflydelse på den samlede sideindlæsningstid.

Resumé

I denne artikel fokuserede jeg på Nginx vs Apache og forklarede de vigtigste arkitektoniske forskelle, der hjalp Nginx med at få mere trækkraft og opmærksomhed inden for webserver-arenaen. Dette er de vigtigste træk, der giver det ydeevnen i vores ressource-sultne industri.

Naturligvis har ikke alle brugssager de samme prioriteter, og Apache eller andre værktøjer som Lighttpd, IIS, LiteSpeed, Caddy kan muligvis være gode løsninger.

Hos Kinsta bruger vi Nginx som en del af vores performance-optimerede hosting-løsninger til WordPress og WooCommerce. Hvert WordPress-sted er indeholdt i sin egen isolerede beholder, der har alle de software-ressourcer, der kræves for at køre det (Nginx, Linux, PHP, MySQL). Ressourcerne er 100% private og deles ikke mellem andre sider.

Sørg for at tjekke Nginx og alle vores premium-tilføjelser ud. Du kan også se vores Application Hosting– og Database Hosting-tjenester for at få flere hostingmuligheder.

Tonino Jankov

Tonino er en iværksætter, Linux & OSS entusiast, udvikler og teknisk underviser. Han har over ti års erfaring med udvikling og har været i blockchain-området i 3+ år. Når han ikke koder, skriver han for SitePoint og Alibaba Cloud, overvåger de nyeste skønlitterære værker på Netflix og udforsker nye rejsedestinationer.

• Twitter