Nginx vs Apache: Webbserver Showdown

Internet, som vi känner det idag, började sin globala ”erövring” på 90-talet. Hela ”Web”-protokollet kan sammanfattas som en besökare som begär ett dokument från en viss webbadress, med DNS och IP-system som vidarebefordrar den begäran till rätt dator. Den här datorn, som hostar den begärda webbsidan, kommer att ”servera” webbsidan tillbaka till besökaren.

Webbsidor är i huvudsak HTML-dokument. För att kunna servera olika webbsidor för besökarna behöver den ”serverande” datorn ett serverprogram. Programvara som Nginx vs Apache hanterar förfrågningar, analyserar dem, och lämnar sedan tillbaka motsvarande dokument som ska visas i en besökares webbläsare.

Apache

Vi dyker in i Apache först eftersom det är äldst.

Efter Tim Berners-Lees CERN httpd och NCSA HTTPd under internets första år, erövrade Apache – först släppt 1995 – snabbt webben och blev världens mest populära webbserver. Numera har det fortfarande denna marknadsposition men mestadels av tradition. Apache utvecklas och underhålls av Apache Foundation, under Apache-licensen.

Det finns två olika historier om hur Apache fick sitt namn. En version säger att namnet härstammar från den berömda Indianstammen, medan den andra säger att namnet är en ordlek på ”a patchy server”, som följde en serie mjukvarupatcher.

Linux

Apaches stora marknadsandel beror delvis på att den kommer förinstallerad med alla stora Linux-distributioner, som Red Hat/Centos och Ubuntu.

Ett exempel på Apaches viktiga roll inom Linux-världen är att dess serverprocessnamn är HTTPd, vilket gör Apache till synonymt med webbserverprogramvara.

Förutom att vara den första seriösa spelaren på webbservermarknaden beror en del av Apaches spridning på dess konfigurationssystem och dess .htaccess-fil.

.htaccess

Apache använder .htaccess för dess konfiguration. Det finns gott om handledning på hur du konfigurerar, redigerar och arbetar med den här filen eftersom den ger stor flexibilitet vid konfigurering av hur Apache hanterar inkommande förfrågningar. Några exempel är: olika omdirigeringsregler, maximala uppladdningsfilstorlekar, URL-omskrivningar, minnesgränser, katalogskydd (htpasswd), expires-rubriker, cache-control-rubriker, kodningsrubriker, cookies, frågesträngsmanipulationer.

Å andra sidan använder Kinsta Nginx som inte stöder .htaccess-filer. Inställningar och regler från dina .htaccess-filer kan dock enkelt ”översattas” till Nginxs egen omskrivningsregelsyntax.

En av de viktigaste ”fördelarna med Apache är att i serverroten – webbplatsens huvudkatalog – kan varje nivå eller katalog i katalogträdet ha sin egen .htaccess-fil med egen konfiguration.

För delade webbhotell, är detta en dröm eftersom de kan ge hundratals användare på samma maskin ett sätt att konfigurera hur deras webbplatser serveras, utan att det påverkar de andra. Kunder kan konfigurera en hel del detaljer i en begränsad delad hostingmiljö, och samtidigt aldrig röra den globala serverkonfigurationen.

Som den officiella dokumentationen säger:

”I allmänhet bör du bara använda .htaccess-filer när du inte har tillgång till konfigurationsfilen för huvudservern.”

Denna flexibilitet kommer dock på bekostnad av prestanda ”att tillåta .htaccess-filer orsakar en prestandanedgång, oavsett om du använder dem eller ej!”

Varje gång .htaccess-filer är aktiverade, måste Apache gå igenom hela katalogträdet från den begärda webbadressen eller filen, genom alla högre nivåer fram till serverns rotkatalog och sedan ladda dem, för varje begäran. Det måste sedan bearbeta dessa filer och omkonfigurera sig själv för var och en av de kataloger som konfigurerats på detta sätt.

Med WordPresswebbplatser, kan saker och ting bli riktigt komplexa. En typisk WordPresswebbplats kan ha hundratals förfrågningar från olika kataloger.

Från/wp-content/uploads/yyyy/mm-typ av dirs, kommer det vanligtvis att ha flera förfrågningar på en enda sidladdning, ofta från olika månads-kataloger. Sedan kommer det att finnas/wp-content/themes/parent-theme statiska resurser, /wp-content/themes/child-theme-resurser: dessa kommer att omfatta JavaScript, CSS-filer, bilder.

Sedan kommer det också att finnas /wp-content/plugins med statiska filer laddade från ofta dussintals plugin-underkataloger. För var och en av dessa resurser måste Apache gå igenom hela sitt träd för att leta efter konfigurationen.

En analys har visat att en typisk WordPress-inställning, ganska vanlig för webbplatser på delade värdar, kommer att innehålla 42 separata .htaccess-exekveringar och 249 separata sökningar för .htaccess-filen.

Och detta är bara på webbserver-nivå. Besökaren behöver fortfarande vänta på att PHP-processen ska utföra alla WordPress-anropningar för att skapa databasförfrågningen och ge den till MySQL för att montera webbsidan och skicka den till besökaren.

Modules

En annan sak som gjorde Apache populär är dess dynamiska modulsystem.

Moduler – som en funktion som tillåter användare att utöka webbserverfunktionalitet – finns både hos Nginx och Apache. Apache låter användare installera moduler när webbservern redan har installerats och distribuerats och sedan aktivera/inaktivera dem efter behov. Debianbaserade distributioner har kommandon som gör det möjligt att aktivera och inaktivera dessa moduler utan att behöva redigera några konfigurationsfiler: a2enmod och a2dismod.

Den officiella listan över moduler som kommer som en del av Apache standarddistribution finns här och dessa inkluderar allt från komprimering, kryptering, loggning, omdirigeringar till mer avancerade saker som redigeringsförfrågningar och svar med avancerad syntax.

Nginx

Nginx (även skrivet som nginx eller NGINX), nådde marknaden 2004, när det först släpptes offentligt av den ryska utvecklaren Igor Sysoev. Som Owen Garrett, Nginxs projektledare, sa:

”Nginx skrevs speciellt för att ta itu med prestandabegränsningarna hos Apache-webbservrar.”

Servern skapades först som ett skalningsverktyg för webbplatsen rambler.ru 2002. Den finns i två versioner: öppen källkod, med BSD-typ licens, och Nginx Plus, med support och ytterligare företagsfunktioner.

Efter att det släpptes användes Nginx mestadels för att servera statiska filer och som en lastbalanserare eller reverse proxy för Apache-installationer. Allteftersom webben utvecklades, och behovet av att pressa fram varje sista droppe av hastighets- och hårdvaruanvändningseffektivitet med det, började fler webbplatser att ersätta Apache med Nginx helt, också tack vare en mer mogen programvara.

Mars 2019 förvärvades Nginx Inc av F5 Networks för $670 miljoner. Vid den tidpunkten, som Techcrunch rapporterar, drev Nginx server ”375 miljoner webbplatser med 1,500 betalande kunder”.

Enligt uppgifter från w3techs har Nginxs marknadsandel stadigt ökat, och håller på att knuffa ut Apache från marknaden och definitivt bort från kungatronen:

Dessa uppgifter avser övergripande webbservrar globalt, men om vi tar kikar endast på de bästa en miljon webbplatserna har Nginx varit där under en lång tid nu:

Google SearchTrends verkar också återspegla detta faktum:

Netcraft-undersökningen tyder på att Apache kördes om av Nginx i April 2019.

Nginx-konfiguration

Nginx har inte ett konfigurationssystem som Apache, så trots att det är mycket effektivare och snabbare, är det inte allmänt använt hos hostingleverantörer. Det lyser inte i delade miljöer som Apache gör.

Men som vi sa, genom att inte tillåta konfigurationer på katalognivå, får å andra sidan Nginx en betydande fördel över Apache. Det finns en artikel på Nginx Wiki som jämför prestandainverkan:

Nginx Moduler

Nginx modulsystem är något som gör det till ett mer prisvärt val. Nginx-moduler behöver vanligtvis aktiveras när det byggs, vilket innebär krav på en mer teknisk förmåga, och efterinstallationen av moduler är lite mer komplicerad.

År 2016, med version 1.9.11, hade saker och ting förändrats och det officiella/verifierade dynamiska modularkivet är reserverat för betalande användare. I maj 2019 tillkännagav de  att de påbörjat utvecklingen av stöd för QUIC och HTTP/3.

Frågan om Cachning: Nginx vs Apache

Cachning – om vi vill förenkla det – kan jämföras med att förbereda innehållet för webbplatsbesökare innan deras besök så att när de ”knackar på dörren” behöver du inte leta efter innehållet som de letar efter. Du har det redan förberett och du överlämnar det till dem utan någon väntetid.

Liksom Apache brukade Nginx typiska inställning vara att sitta mellan servrar och slutanvändare för att lindra prestandaminskningen på resten av infrastrukturen. I dessa fall kan det cacha statiskt innehåll utan att behöva hämta det från den skyddade ursprungsservern varje gång.

Om vi använder Nginx som en fristående webbserver – som är fallet med Kinsta LXC-container – finns det inget sådant behov. Nginx är mycket effektiv i att servera statiskt innehåll på egen hand.

Sedan är det frågan om dynamisk cache eller sidcache. I en WordPresswebbplats-situation innebär detta att lagra alla WordPress-sidor som genereras för varje URL i minnet eller på disk.

FastCGI-cachning är alltid tillgängligt i en standard Nginx-installation. Det är enkelt, mycket kraftfullt och en av de mindre använda Nginx-funktionerna.

För att jämföra detta med Apache-ekvivalenter bör du veta att Apache har en mod_cache-modul som enligt uppgift tenderar att ofta få problem, och är i konflikt med andra moduler. Så standard cachningslösning som kommer med Apache är Varnish HTTP-accelerator. Även om Varnish är den dedikerade industrilösningen, ger några nyligen gjorda tester Nginx-cachning en klar fördel över Varnish.

På Kinsta använder vi Nginx för dynamisk WordPress-cachning, tillsammans med ett proprietärt cachningsplugin som tillåter granulär kontroll över cachade sidor, och statiska tillgångar cachade av Kinsta CDN.

Hantering Av Förfrågningar: Nginx vs Apache

Den största skillnaden mellan Apache och Nginx ligger i den underliggande arkitekturen för hur de hanterar förfrågningar.

Apache bearbetar förfrågningar med MPM-s eller Multi-Processing-moduler, som ”ansvarar över att bindas till nätverksportar på maskinen, acceptera förfrågningar och skicka ’barn’ att hantera förfrågningar.”

Den äldsta MPM:n, som går tillbaka hela vägen till Apaches början, är prefork-modulen. Denna modul kan ensam anser ansvarig för Apache dåliga prestandarykte. I det här läget skapar Apache en ny process med en tråd för varje förfrågan.

Den här modulen, som användes med mod_php, innebar att Apache-servern inbäddade en PHP-tolk i varje enskild process, även om den var tvungen att servera CSS-filer eller bilder. Detta var ineffektivt. Prefork-modulen levereras med Apache som standardmodul. Det begränsar också anslutningar till HTTP/1.

Under senare år har Apache utvecklat flertrådade worker mpm och därefter event mpm. Båda dessa lindrar många av Apaches prestandaproblem. Att byta till php-fpm gör det möjligt för Apache att fortfarande vara en konkurrerande lösning idag, tillsammans med att eliminera användningen av .htaccess, men den besegrar lite dess syfte.

Nginx använder asynkron, icke-blockerande händelsedriven arkitektur.

För att förklara skillnaden: i Linux/Unix-världen körs program av processer.

Trådar är en sorts processer och det kan finnas flera trådar inom en process-exekvering. Tänk på detta som flera flikar i ett webbläsarfönster. På så sätt kan ett program utnyttja flera CPU-s och fler-kärnade, fler-trådade CPU-s för att jobba snabbare. Du kan läsa när Linus Torvalds går igenom skillnaderna.

Kort sagt, Apache använder processer för varje anslutning (och med worker mpm använder det trådar). När trafiken stiger blir det snabbt för dyrt.

Vi kan tänka oss en ny process eller trådskapande som att starta upp en dator eller starta upp program. Även på den snabbaste av datorer, tar det fortfarande en liten stund. Med webbplatser idag gör hundratals förfrågningar på en enda sidladdning, som snabbt läggs ihop till en hel del.

Event mpm kommer lite längre när det gäller optimering, men vissa tester visar att det inte kan klå Nginx. Speciellt när vi pratar om statiska filer, där Nginx servar dubbelt så många förfrågningar som Apache gör.

Nginx har idealiskt en arbetar-process per CPU/kärna. Skillnaden mellan Nginx arbetar-processer är att var och en kan hantera hundratusentals inkommande nätverksanslutningar per arbetare. Det finns inget behov av att skapa nya trådar eller processer för varje anslutning.

Detta är anledningen till att stora innehållsleveransnätverk, som CloudFlare, MaxCDN och vår partner KeyCDN – eller webbplatser som Netflix – anser Nginx vara avgörande för deras innehållsleverans.

Listan över företag som utnyttjar Nginx är för lång för att lista dem alla, så vi kommer att sluta med Automattic, det privata företaget bakom WordPress.com. Automattic konverterade alla sina lastbalanserare till Nginx för WordPress.com under 2008 (du kan läsa om det här) och migrerade sin serverstack helt till Nginx.

Kontrollera det i verkliga livet

Om vi vill inspektera vad en produktionswebbplats använder, kan vi vanligtvis hitta detta i HTTP-svarsrubriker. Det betyder att vi måste högerklicka på en webbplats > Inspektera, i utvecklarverktygen väljer vi nätverkspanelen och laddar sedan om webbplatsen. Vi ser alla resurser som webbplatsen laddar. Om vi väljer en viss resurs och dess rubriker, ser vi vanligtvis serverinformationen. Om webbplatsen använder CDN kan vi se något som CloudFlare i serverlinjen eller något som Varnish om webbplatsen använder en HTTP-accelerator.

Detta är ett exempel på en WordPress-webbplats som använder en typisk delad hosting-lösning med cPanel, Apache och PHP:

Detta är en webbplats på Nginx:

På vänster sida, om vi expanderar den, kommer vi också att kunna analysera tiden för varje resurs och se dess inverkan på den totala sidladdningstiden.

Sammanfattning

I den här artikeln fokuserade jag på Nginx vs Apache och förklarade de viktigaste arkitektoniska skillnaderna som hjälpte Nginx att få mer dragkraft och uppmärksamhet inom webbserver-världen. Det här är de viktigaste egenskaperna som ger den en prestandafördel i vår resurshungriga industri.

Naturligtvis har inte varje användare samma prioriteringar och Apache eller andra verktyg som Lighttpd, IIS, LiteSpeed, Caddy kan vara bra lösningar.

På Kinsta använder vi Nginx som en del av våra prestandaoptimerade webbhotell för WordPress och WooCommerce. Varje WordPresswebbplats är inrymt i sin egen isolerade container, som har alla programresurser som krävs för att köra den (Nginx, Linux, PHP, MySQL). Resurserna är 100% privata och delas inte mellan andra webbplatser.

Se till att kolla in Nginx och alla våra premiumtillägg. Kolla även in våra tjänster för applikationshosting och databashosting för fler hosting-möjligheter.

Tonino Jankov

Tonino är en entreprenör, Linux- och OSS-entusiast, utvecklare och teknisk utbildare. Han har över tio års erfarenhet av utveckling och har varit i blockchain-området i 3+ år. När han inte kodar skriver han för SitePoint och Alibaba Cloud, tittar på de senaste skönlitterära verken på Netflix och utforskar nya resmål.

• Twitter