Het internet, zoals we het vandaag de dag kennen, begon in de jaren negentig met zijn verovering van de wereld. Het hele “web”-protocol kan als volgt worden samengevat. Een bezoeker vraagt een document op van een zeker webadres waarbij het DNS- en IP-systeem het verzoek doorsturen naar de juiste computer. Die computer, die de aangezochte webpagina host, gaat de bezoeker bedienen en dient dus als ‘server’. 

Webpagina´s zijn in wezen HTML-documenten. Om de diverse webpagina´s te kunnen serveren aan de bezoekers, heeft de “serverende” machine een server-programma. Software, zoals Nginx vs Apache, nemen de verzoeken in behandeling, bestuderen ze en leveren daarna de bijbehorende documenten die vervolgens worden getoond op het scherm van de bezoeker.

Apache

We behandelen Apache als eerste, aangezien deze server het langste bestaat.

Na Tim Berners-Lee´s CERN httpd en NCSA HTTPd in de eerste jaren van het internet, veroverde Apache – uitgebracht in 1995 – al vrij snel de markt en werd dit de meest populaire webserver ter wereld. Vandaag de dag bezet hij die marktpositie nog steeds, maar dat is vooral om historische redenen. Apache wordt ontwikkeld en onderhouden door de Apache Foundation, onder de Apache-licentie.

Er gaan twee verhalen over hoe Apache aan zijn naam kwam. De ene vertelt dat de naam zijn oorsprong vindt in het bekende indiaanse erfgoed.  De andere beweert dat de naam een woordgrapje is en is afgeleid van “a patchy server”, na een reeks onregelmatigheden (patches) met de software. Waarbij je voor het goede begrip even moet weten dat Amerikanen “Apache” uitspreken als “a patchy”. Maar misschien zijn het allebei indianenverhalen. 

Linux

Het enorme marktaandeel van Apache is grotendeels te danken aan het feit dat het vooraf al geïnstalleerd is op alle grote Linux-distributies, zoals Red Hat/Centos en Ubuntu.

Standaardpagina Ubuntu

Standaardpagina Ubuntu

Het beste voorbeeld van de relevantie van Apache binnen de Linux-wereld is dat zijn serverprocesnaam HTTPd is. Oftewel, Apache is binnen Linux synoniem met webserversoftware.

Behalve dat Apache de eerste serieuze speler was op de markt van webservers, heeft zijn wereldwijde verspreiding voor een deel ook te maken met zijn configuratiesysteem en zijn .httaccess-bestand.

.htaccess

Apache gebruikt .htaccess voor zijn configuratie. Er bestaan veel tutorials over hoe men met dit bestand configureert, bewerkt en ermee omgaat, aangezien dit bestand veel bewegingsruimte biedt bij het configureren van hoe Apache inkomende bezoeken behandelt. Enkele voorbeelden zijn: verschillende omleidingsregels, maximale grootte uploadbestanden, URL-herschrijvingen, geheugenlimieten, mapbescherming (htpasswd), expires headerscache-control headersencoding headers, cookies, queryreeksmanipulaties.

Het is nou wel zo dat Kinsta gebruikmaakt van Nginx, dat geen .htaccess-bestanden ondersteunt. Echter, instellingen en regels in jouw .htaccess-bestanden kunnen eenvoudig “vertaald” worden naar de eigen herschrijfregelsyntaxis van Nginx.

Eén van de grootste “voordelen” van Apache is dat in de root van de server — de hoofdmap van de website — elk niveau of elke map in de mappenstructuur een eigen .httaccess-bestand met een eigen configuratie kan hebben.

Voor aanbieders van gedeelde hosting is dat een droom, omdat ze honderden gebruikers een manier kunnen bieden om te configureren hoe ze willen dat hun websites worden bediend, zonder dat ze hiermee invloed hebben op andere websites. Klanten kunnen een heleboel details configureren in een beperkte gedeelde hostingomgeving, zonder ooit te interfereren met de algemene configuratie van de server.

Zoals de officiële documentatie aangeeft:

“In algemene zin zou je eigenlijk alleen .htaccess-bestanden moeten gebruiken als je geen toegang hebt tot het configuratiebestand van de hoofdserver.”

Deze flexibiliteit gaat evenwel ten koste van de prestaties: “het toestaan van .htaccess-bestanden veroorzaakt een teruggang in prestaties, ongeacht of je ze gebruikt of niet!”

Steeds wanneer er .htaccess-bestanden worden geactiveerd, moet Apache de complete mappenstructuur van de gevraagde URL of het bestand doorlopen, alle hogere niveaus helemaal tot aan de hoofdmap van de server, en ze dan laden – elke keer weer voor elke aanvraag. Daarna moet hij deze bestanden verwerken en zichzelf opnieuw configureren voor elk van de mappen die op deze wijze geconfigureerd is.

Met WordPress-websites kan dat allemaal knap gecompliceerd worden. De gemiddelde WordPress-website kan honderden aanvragen hebben van verschillende mappen.

Van mappen van het type /wp-content/uploads/yyyy/mm- gaat de site normaalgesproken verschillende aanvragen hebben bij het laden van een enkele pagina, veelal van verschillende maandmappen. Denk hierbij aan statische resources van /wp-content/themes/parent-theme en resources van /wp-content/themes/child-theme. Daar zitten bij: javascript, CSS-bestanden, afbeeldingen.

Dan zijn er ook nog: /wp-content/plug-ins met statische bestanden die binnengehaald worden van vaak tientallen submappen van plug-ins. Voor elk van deze bronnen moet Apache voor de configuratie zijn hele structuur doorploegen.

Een analyse heeft aangetoond dat een gemiddelde WordPress-configuratie, heel gewoon voor websites bij gedeelde hosts, te maken krijgt met 42 afzonderlijke .htaccess-bewerkingen en 249 zoekopdrachten naar het .htaccess-bestand.

En dat is alleen nog maar op webserverniveau. De bezoeker moet vervolgens nog wachten op de executie van de gehele WordPress-aanroepstack voor het aanmaken van de databasequery en op doorgifte aan MySQL voor het samenstellen van de webpagina die uiteindelijk aan de bezoeker toegestuurd wordt.

Modules

Iets anders waardoor Apache erg gewild werd, is zijn dynamische modulesysteem.

Modules — in de zin van functies die gebruikers in staat stellen webserverfunctionaliteit uit te breiden — zijn er zowel in Nginx als in Apache. Apache biedt gebruikers de mogelijkheid modules te installeren als de webserver al lang en breed geplaatst en in gebruik genomen is, die ze daarna naar behoeven aan- of uitzetten. Op Debian gebaseerde distributies hebben de beschikking over opdrachten die deze modules aan en uit kunnen zetten zónder enig configuratiebestand te hoeven bewerken: a2enmod en a2dismod.

De officiële lijst van modules die standaard met de Apache-distributie meegeleverd worden, vind je hier. En de inhoud varieert van dingen als compressie, encryptie, logboekregistratie, omleidingen tot meer geavanceerde zaken, zoals het bewerken van aanvragen en antwoorden met een vergevorderde syntaxis.

Nginx

Nginx (ook wel geschreven als nginx of NGINX) kwam in beeld in 2004, toen het voor het eerst uitgebracht werd door de Russische ontwikkelaar Igor Sysoev. Owen Garrett, projectmanager van Nginx zei daarover:

“Nginx werd eigenlijk alleen geschreven vanwege de beperkingen in prestaties van Apachewebservers.”

De server werd in 2002 in eerste aanleg gemaakt als hulpmiddel voor het schalen van de website rambler.ru. Hij kent twee versies: open source, met licentietype BSD, en Nginx Plus, met ondersteuningsvoorzieningen en extra mogelijkheden voor ondernemingen.

Toen Nginx net was uitgebracht werd het vooral gebruikt om statische bestanden te leveren en als netwerktaakverdeler of omgekeerde proxy aan de voorkant van Apache-installaties. Toen het web zich verder ontwikkelde – en daarmee de behoefte om elke nanoseconde tijdwinst te benutten en elke watt van het hardwarevermogen efficiënt te gebruiken – gingen steeds meer websites Apache in zijn geheel vervangen door Nginx, mede dankzij zijn meer volwassen software.

NGINX Inc overgenomen door F5 Networks

NGINX Inc overgenomen door F5 Networks

In maart 2019 werd Nginx Inc voor $670 miljoen ingelijfd bij F5 Networks. Volgens Techcrunch bediende de Nginx-server op dat moment “375 miljoen websites, met 1500 betalende klanten”.

Volgens gegevens van w3techs is het marktaandeel van Nginx gestaag blijven groeien, waarbij het Apache inhaalde en diens leidende positie overnam:

Webservergebruik

Webservergebruik

Deze gegevens slaan op alle webservers wereldwijd, maar als we het gaan hebben over de top miljoen websites, dan staat Nginx daar al wat langer aan de top:

Percentage websites dat gebruikmaakt van Nginx

Percentage websites dat gebruikmaakt van Nginx

Google Search Trends bevestigt die tendens:

Google Search Trends: Nginx vs Apache

Google Search Trends: Nginx vs Apache

Een peiling van Netcraft suggereert dat Apache in april 2019 werd ingehaald door Nginx.

Nginx-configuratie

Nginx heeft niet een configuratiesysteem zoals Apache. Met andere woorden, ondanks het feit dat het veel doelmatiger en sneller is, vindt het nog geen brede toepassing bij aanbieders van hosting aan consumenten. Het komt daarnaast niet goed uit de verf in gedeelde omgevingssituaties, waarin Apache dat wel doet.

Aan de andere kant is het zo dat Nginx een belangrijk voordeel heeft ten opzichte van Apache omdat het, zoals we al eerder aangaven, geen configuraties toestaat op mappenniveau. Er staat een artikel op Nginx wiki dat de gevolgen voor de prestaties met elkaar vergelijkt:

Nginx vs Apache.png: impact op prestaties

Nginx vs Apache.png: impact op prestaties

Nginx-modules

Het modulesysteem van Nginx is een ander punt dat in zijn voordeel spreekt. Nginx-modules dienen normaalgesproken ingeschakeld te worden tijdens de bouw. Dat betekent dat er meer technische kennis bij komt kijken en dat het lastig is modules toe te voegen ná installatie.

Met het uitkomen van versie 1.9.11 in 2016 veranderde er een hoop. De opslagplaats van officiële (dan wel gecontroleerde) dynamische modules is strikt voorbehouden aan betalende gebruikers. En ze hebben aangekondigd dat ze vanaf mei 2019 van start gaan met het ontwikkelen van ondersteuning voor QUIC en HTTP/3.

De kwestie van opslag in cache: Nginx vs Apache

Opslaan in cache kunnen we — als we het heel erg simpel voorstellen — beschrijven als: de content voor websitebezoekers al klaar hebben staan nog vóór ze erom vragen. Met andere woorden, je hoeft de inhoud die ze willen hebben, al niet meer eerst bijeen te sprokkelen. Je hebt het al klaarliggen en je overhandigt het zonder dat ze er een tel op hoeven wachten.

Net zoals Apache zit de opstelling van Nginx ook ergens tussen de servers en de eindgebruiker om de teruggang in prestatie op te vangen met de rest van de infrastructuur. In zulke gevallen kan het statische inhoud in cache opslaan zonder die steeds eerst van de afgeschermde originele server te hoeven halen.

Als we Nginx gebruiken als een op zichzelf staande webserver— zoals het geval is bij Kinsta met haar LXC-containers – dan is die behoefte er niet. Nginx is namelijk onwijs efficiënt wat betreft het uitserveren van statische content.

Dan is er nog de kwestie van dynamic cache of paginacache. In het scenario van een WordPress-website betekent dit dat alle voor iedere URL gegenereerde WordPress-pagina´s in het geheugen of op schijf worden opgeslagen.

FastCGI caching is standaard beschikbaar in een normale Nginx-installatie. Het is eenvoudig, enorm krachtig en toch één van de minst algemeen gangbare Nginx-functies.

Als je dit afzet tegen Apache-equivalenten, moet je je wel realiseren dat Apache een mod_cache-module heeft. Die heeft naar verluidt nogal eens kuren en conflicteert snel met andere modules. De standaardoplossing voor opslaan in cache die gebruikt wordt in Apache, is daarom Varnish HTTP accelerator. Hoewel Varnish de gebruikelijke oplossing is in de branche, hebben enkele recent uitgevoerde tests een duidelijke voorkeur gegeven aan Nginx-caching boven Varnish.

Bij Kinsta maken we gebruik van Nginx voor dynamic caching in WordPress, samen met een eigen cacheplug-in die uitgebreid beheer van de pagina´s in cache toestaat, alsmede statische assets, in cache opgeslagen door Kinsta CDN.

Afhandeling van aanvragen: Nginx vs Apache

Het grootste verschil tussen Apache en Nginx zit hem in de onderliggende architectuur, in de wijze hoe ze aanvragen afhandelt.

Apache behandelt aanvragen met Multi-Processing-Modules (MPM), “verantwoordelijk voor de binding met netwerkpoorten op de machine, die de aanvragen accepteert en children uitstuurt om de aanvragen af te handelen.”

De oudste MPM, die al bijna net zo lang als Apache bestaat,  is prefork module. Overigens is het deze module die voor de slechte reputatie van Apache wat betreft prestaties heeft gezorgd. In deze modus roept Apache nieuw processen aan met één thread per aanvraag.

Deze module, die gebruikt wordt met mod_php, betekende dat Apache-server een PHP-interpreter betrok bij elk en ieder proces, zelfs als hij simpele CSS-bestanden of afbeeldingen moest leveren.

Dit was verre van efficiënt. Prefork module zit standaard op Apache. Het beperkt bovendien verbindingen met HTTP/1.

In latere jaren ontwikkelde Apache worker mpm die meer threads tegelijkertijd ondersteunt. En nog later event mpm. Beide maken veel goed van de prestatieproblemen waar Apache mee kampt. Overschakelen op php-fpm maakt het Apache tegenwoordig mogelijk om weer te concurreren met de marktleiders. Het maakt het gebruik van .htaccess overbodig en schiet zo als het ware zijn doel voorbij.

Nginx maakt gebruik van asynchrone, niet-blokkerende, door events aangestuurde architectuur.

Om het verschil aan te geven: in de Linux/Unix-wereld worden processen gerund door programma´s.

Een thread is een subset aan processen. Er kunnen een stuk of wat threads in de uitvoering van één proces zitten. Beschouw het voor het gemak even als meerdere tabbladen in een browservenster. Op deze manier kan een programma van meerdere CPU´s ´gebruikmaken – van multi-core, multi-thread CPU´s, voor een snellere afhandeling. Je kunt hier lezen hoe Linus Torvalds de verschillen uitwerkt.

Om kort te gaan, Apache gebruikt processen voor elke verbinding (en met worker mpm gebruikt het threads). Als de drukte toeneemt, wordt het algauw te veel.

We kunnen ons het aanmaken van een nieuw proces of nieuwe thread voor de geest halen. Denk maar eens aan het opstarten van een computer of aan het openen van programma´s. Zelfs op de snelste computer vergt het domweg enige tijd. Vandaag de dag met websites die honderden aanvragen tegelijk doen voor het opbouwen van een enkele pagina, loopt dat aardig op.

Event mpm gaat een stukje verder als het gaat om optimalisatie. Niettemin geven sommige tests aan dat het Nginx op dit punt niet kan verslaan. Vooral als we het hebben over statische bestanden, waar Nginx het dubbele aan aanvragen haalt van wat Apache aankan.

Nginx heeft idealiter één werkproces per CPU/core. Het verschil van  Nginx-werkprocessen is dat elk ervan honderdduizenden inkomende verbindingen tegelijk kan afhandelen. Het is helemaal niet nodig nieuwe threads of processen aan te maken voor elke verbinding. 

Dit is de reden waarom de grote spelers in de Content Delivery Networks, zoals Cloudflare, MaxCDN en onze partner KeyCDN — of websites als Netflix — Nginx als cruciaal beschouwen voor de aflevering van hun content.

De lijst van bedrijven die baat hebben bij Nginx is te lang om op te sommen. Daarom besluiten we met Automattic, het particuliere bedrijf achter WordPress.com.

In 2008 zette Automattic al zijn loadbalancers over naar Nginx voor WordPress.com (je kunt hier meer lezen) en het migreerde bovendien zijn serverstack naar Nginx.

En hoe werkt dat nou in de praktijk

Als we willen nagaan wat een website gebruikt als hij live draait, kunnen we dat gewoonlijk vinden in de HTTP response-headers. Dit betekent dat we rechts moeten klikken op een website > Inspect, in de developer tools, kiezen we het netwerkpaneel en laden daarna de website opnieuw. We zullen alle bronnen te zien krijgen die de website laadt. Als we een bepaalde bron aankiezen en zijn Headers-tabblad, krijgen we normaliter de serverinformatie voorgeschoteld. Als de website gebruikmaakt van CDN kan het zijn dat we iets te zien krijgen als Cloudflare in de serverregel, of iets als Varnish, indien de website gebruikmaakt van http-accelerator.

Hier volgt een voorbeeld van een WordPress-website die van een configuratie met CPanel, Apache en PHP gebruikmaakt, die typerend is voor gedeelde hosting:

http-header Apache

http-header Apache

En dit is een website op Nginx:

HTTP header Nginx

HTTP header Nginx

Als we het uitvergroten kunnen we aan de linkerkant tevens de tijd van elke bron analyseren en de uitwerking die het heeft op de totale paginalaadtijd.

Nginx vs Apache: welk van de twee biedt de snelste oplossing voor jouw WordPress-sites? 🚀 Kijk eens goed naar onze confrontatie tussen de twee webservers! Click to Tweet

Samenvatting

In dit artikel richtte ik me op Nginx en Apache. Ik legde de belangrijkste verschillen in architectuur uit die Nginx uiteindelijk de winnende hand gaven in de webserverarena. Dat zijn de sleutelkenmerken die het een prestatief voordeel verleenden in onze altijd ontwikkelende industrietak.

Niet iedere use-case heeft natuurlijk dezelfde prioriteiten. En Apache of andere hulpprogramma´s, zoals LighttpdIISLiteSpeedCaddy, zouden ook best goede oplossingen kunnen zijn.

Bij Kinsta gebruiken we Nginx als onderdeel van onze voor performance  geoptimaliseerde hostingoplossingen voor WordPress en WooCommerce. Elke WordPress-site is gehuisvest in zijn eigen geïsoleerde cel, die alle softwarehulpbronnen tot zijn beschikking heeft om de site te kunnen runnen (Nginx, Linux, PHP, MySQL). De bronnen zijn volledig privé en worden niet gedeeld met enige andere site.

22
Delen