Nginx vs Apache: de krachtmeting tussen de twee populairste webservers ter wereld

Het internet, zoals we dat vandaag de dag kennen, begon zijn globale opmars in de jaren ’90. In feite kan je dit “Web”-protocol als volgt samenvatten: een bezoeker vraagt een document aan vanaf een bepaald webadres, waarbij DNS- en IP-systemen het verzoek doorsturen naar de juiste computer. Deze computer, die de gevraagde webpagina host, “serveert” vervolgens de webpagina aan de bezoeker.

Webpagina’s zijn in wezen HTML-documenten. Om verschillende webpagina’s aan de bezoekers te kunnen aanbieden, heeft de “serverende” machine een serverprogramma nodig. Software zoals Nginx vs Apache verwerkt de verzoeken, analyseert ze en geeft vervolgens de bijbehorende documenten terug. Deze kunnen vervolgens worden bekeken in de browser van de bezoeker.

Apache

We beginnen met Apache, omdat deze het eerst werd uitgebracht.

In de vroege jaren van het internet was het Tim Berners-Lee’s CERN HTTPD en NCSA HTTPd dat de klok sloeg. Daarna was het Apache – voor het eerst uitgebracht in 1995 – dat snel de markt veroverde en zichzelf kroonde tot ’s werelds populairste webserver. Tegenwoordig bevindt het zich nog steeds in die positie, maar dat komt vooral door het hoge aandeel van de vele verouderde sites die van deze server gebruik maken. Apache wordt ontwikkeld en onderhouden door de Apache Foundation, onder de Apache-licentie.

Er doen zich twee verschillende verhalen de ronde over hoe Apache zijn naam kreeg. Eén versie stelt dat de naam afkomstig is van de indianen, terwijl de andere de oorsprong van de naam toewijst aan de woordspeling “a patchy server”, die werd toegekend na een periode waarin patches elkaar kort na elkaar opvolgden.

Linux

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

Een voorbeeld die de belangrijke rol van Apache binnen Linux onderstreept, is dat de naam van het serverproces HTTPd is, waardoor Apache synoniem is geworden met webserversoftware.

Naast het feit dat het de eerste serieuze speler op de webservermarkt was, is een deel van Apache’s enorme marktaandeel te danken aan het configuratiesysteem en het .htaccess-bestand.

.htaccess

Apache gebruikt .htaccess voor zijn configuratie. Er zijn online genoeg tutorials te vinden over het configureren, bewerken en werken met dit bestand. Dit bestand zorgt voor veel flexibiliteit bij het configureren van hoe Apache inkomende aanvragen verwerkt. Enkele voorbeelden zijn: verschillende omleidingsregels, maximale grootte bij uploaden bestanden, URL-herschrijvingen, geheugenlimieten, mapbescherming (htpasswd), expires headers, cache-control headers, encoding headers, cookies en manipulaties van queryreeksen.

Aan de andere kant bevindt zich Nginx, waar ook Kinsta gebruik van maakt. Deze ondersteunt geen .htaccess-bestanden. De instellingen en regels binnen je .htaccess-bestanden kunnen echter eenvoudig worden “vertaald” naar de syntaxis van de herschrijfregels van Nginx.

Een van de voordelen van Apache is dat in de serverroot – de hoofdmap van de website – elk niveau of elke map in de mapstructuur zijn eigen .htaccess-bestand kan hebben – met elk zijn eigen configuratie.

Voor aanbieders van shared hosting is dit ideaal, omdat ze op een machine honderden gebruikers hun eigen configuraties kunnen laten instellen, zonder dat dit de sites van anderen beïnvloedt. Klanten kunnen enorm veel configureren binnen een beperkte shared hosting-omgeving, zonder de globale serverconfiguratie aan te raken.

Zoals de officiële documentatie zegt:

“Over het algemeen zou je de .htaccess-bestanden alleen moeten gebruiken wanneer je geen toegang hebt tot het configuratiebestand van de hoofdserver”.

Deze flexibiliteit gaat echter ten koste van de prestaties. “Het toestaan van .htaccess-bestanden heeft een negatieve invloed op de prestaties” of je ze nou daadwerkelijk gebruikt of niet!”

Elke keer als .htaccess-bestanden zijn ingeschakeld, moet Apache de hele mapstructuur doorlopen van de URL of het bestand in kwestie. Dit moet gebeuren voor elk verzoek. Vervolgens moeten deze bestanden worden verwerkt en moet de server zichzelf opnieuw configureren voor elk van de mappen die op deze manier zijn geconfigureerd.

Dit kan al gauw erg complex worden, helemaal bij WordPress-sites. Een typische WordPress-website kan honderden aanvragen uit verschillende mappen bevatten.

Als je kijkt naar mappen met een structuur als /wp-content/uploads/yyyy/mm (waarin yyyy voor het jaartal staat en mm voor de maand), dan betekent dit voor een enkele pagina meestal meerdere aanvragen, vaak vanuit verschillende van dit soort maand-mappen. Dan heb je ook nog statische bronnen als /wp-content/themes/parent-thema en /wp-content/themes/child-thema: deze bevatten javascript, CSS-bestanden, afbeeldingen.

Vergeet ook niet de map /wp-content/plugins met statische bestanden die vaak vanuit tientallen plugin-submappen worden geladen. Voor elk van deze bronnen moet Apache de hele directory-tree doorkruisen om de juiste configuratie te vinden.

Een analyse toonde aan dat een typische WordPress-configuratie, vrij gebruikelijk op shared hosts, 42 afzonderlijke .htaccess-uitvoeringen bevatten met 249 afzonderlijke entries naar het .htaccess-bestand.

En nu hebben we het alleen nog maar over het niveau van de webserver gehad. De bezoeker moet ook nog wachten totdat het hele PHP-proces wordt uitgevoerd door de WordPress-callstack. Deze moet een databasequery maken, deze doorgeven aan de MySQL om een webpagina samen te stellen en alles vervolgens naar de bezoeker sturen.

Modules

Lets anders dat Apache zo populair maakte is zijn dynamische modulesysteem.

Modules – een feature waarmee gebruikers de functionaliteiten van de webserver kunnen uitbreiden – bestaan zowel in Nginx als Apache. Met Apache kunnen gebruikers modules installeren op een reeds geïnstalleerde en geactiveerde installatie. Vervolgens kunnen de modules naar believen in- en uitgeschakeld worden. Debian gebaseerde distributies hebben opdrachten (commands) waarmee deze modules in- en uitgeschakeld kunnen worden zonder configuratiebestanden te hoeven bewerken: a2enmod en a2dismod.

De officiële lijst met modules die deel uitmaken van de standaarddistributie van Apache kan je hier vinden. Deze bevat zaken als compressie, codering, logboekregistratie, omleidingen tot meer geavanceerde dingen als het bewerken van verzoeken en responses met geavanceerde syntaxis.

Nginx

Nginx (ook wel geschreven als nginx of NGINX) verscheen in 2014 toen het voor het eerst werd uitgebracht door de Russische developer Igor Sysoev. Zoals Owen Garrett, de projectmanager van Nginx, zei:

“Nginx is specifiek geschreven om de prestatiebeperkingen van Apache-webservers aan te pakken.”

De server was initieel gemaakt als scalingtool voor de website rambler.ru in 2002. Er zijn twee versies: opensource met BSD-type licentie en Nginx Plus met ondersteuning en extra enterprise-features.

Na de release werd Nginx vooral gebruikt om statische serverbestanden te leveren en om als loadbalancer of reverse-proxy te fungeren voor Apache-installaties. Naarmate het web evolueerde en efficiënt gebruik van snelheid en hardware de norm werd, begonnen meer websites Apache volledig te vervangen door Nginx.

In maart 2019 werd bekend dat Nginx was overgenomen door F5 Networks voor een bedrag van $670 miljoen. Volgens de rapporten van Techcrunch werd de Nginx-server gebruikt door “375 miljoen websites met ongeveer 1.500 betalende klanten”.

Volgens gegevens van w3techs is het marktaandeel van Nginx sindsdien gestaag gegroeid, waardoor Apache van de eerste plaats is gegooid:

Deze gegevens hebben betrekking op algemeen gebruik van webservers wereldwijd. Nemen we echter alleen de top 1 miljoen websites, dan staat Nginx al wat langer op de eerste plek:

Google Search Trends lijkt dit te weerspiegelen:

Onderzoek van Netcraft lijkt te bevestigen dat Apache in april 2019 is ingehaald door Nginx.

Configuratie Nginx

Nginx heeft geen configuratiesysteem zoals Apache en wordt dus niet door veel retail hostingproviders gebruikt, ondanks dat het veel efficiënter en sneller is. Het doet het simpelweg minder goed in de wereld van shared hosting dan Apache.

Aan de andere kant heeft Nginx, zoals gezegd, een aanzienlijk voordeel ten opzichte van Apache door directory-configuraties niet toe te staan. Er is een artikel op de Nginx wiki waarin de impact hiervan op de prestaties wordt vergeleken:

Modules Nginx

Het modulesysteem van Nginx is een van de redenen waarom het platform zich steeds meer als een premium keuze positioneert. Nginx-modules moeten meestal worden ingeschakeld tijdens het bouwen, wat betekent dat er meer technische bekwaamheid bij betrokken is, en het toevoegen van modules na de installatie is ingewikkelder.

In 2016 kwam hier met versie 1.9.11 verandering in en kan de officiële/geverifieerde dynamische modulesrepository worden gebruikt door betalende klanten. In mei 2019 kondigde het bedrijf aan dat ze zouden beginnen met het ontwikkelen van ondersteuning voor QUIC en HTTP/3.

Caching: Nginx versus Apache

Caching – simpel gezegd – is het zo goed mogelijk voorbereiden op de komst van een bezoeker. Dit doe je door te zorgen dat de server de content al klaar heeft staan op het moment dat de bezoeker “bij je aanklopt”. Op die manier hoeft de pagina dus niet bij elkaar gezocht te worden. Hij staat al klaar en je kan hem dus zonder vertraging leveren.

Net als Apache bevindt de typische opstelling van Nginx zich tussen server en eindgebruiker en verlicht hiermee de infrastructuur en verbetert dus de prestaties. In deze gevallen kan statische content dus gecachet worden en hoeft deze dus niet elke keer opgehaald te worden van de beschermde origin server.

Als we Nginx als een zelfstandige webserver gebruiken – zoals het geval is met de LXC-containers van Kinsta – is dat niet nodig. Nginx is zeer efficiënt in het zelfstandig aanbieden van statische content.

Dan is er de kwestie van dynamische cache of paginacache. In het geval van een WordPress-website betekent dit dat alle WordPress-pagina’s die voor elke URL worden gegenereerd, opgeslagen worden in het geheugen of op de harde schrijf.

FastCGI-caching is standaard beschikbaar in een standaard Nginx-installatie. Het is een simpele, zeer krachtige feature van Nginx en wordt verrassend genoeg weinig gebruikt.

Als je deze feature wil vergelijken met die van Apache, dan moet je weten dat Apache een mod_cache module heeft die naar verluidt glitchy is en kan conflicteren met andere modules.  De standaard cachingoplossing van Apache is dus Varnish HTTP-accelerator. Hoewel Varnish de meest gebruikte oplossing is, gaven een aantal recente test Nginx een duidelijk voordeel ten opzichte van Varnish.

Bij Kinsta gebruiken we Nginx voor dynamische WordPress-caching, samen met een eigen cachingplugin die granulaire controle mogelijk maakt over gecachete pagina’s en statische assets die door Kinsta CDN worden gecachet.

Het afhandelen van verzoeken: Nginx versus Apache

Het grootste verschil tussen Apache en Nginx zit hem in de onderliggende architectuur van hoe ze verzoeken afhandelen.

Apache verwerkt verzoeken met MPM-s of Multi-Processing-Modules, die “verantwoordelijk zijn voor het koppelen van netwerkpoorten aan de machine, het accepteren van verzoeken en het uitzetten van children om de verzoeken af te handelen”.

De oudste MPM, die helemaal teruggaat tot de begindagen van Apache, is prefork module. Eigenlijk kan de hele reputatie van Apache’s slechte performance worden teruggebracht naar deze module. In deze modus maakt Apache voor elk verzoek een nieuw proces aan met één thread.

Deze module, gebruikt met mod_php, zorgt ervoor dat de Apache-server voor elk afzonderlijk proces een PHP-interpreter moet activeren, zelfs al gaat het om het leveren van CSS-bestanden of afbeeldingen.

Dit was heel inefficiënt. Prefork module wordt als standaardmodule geleverd met Apache. Ook beperkt het de verbindingen tot HTTP/1.

In latere jaren heeft Apache de multi-threaded worker mpm ontwikkeld en vervolgens de event mpm. Beide hebben veel van de performance-issues met Apache verlicht. Overschakelen naar php-fpm maakt het voor Apache mogelijk om nog steeds een concurrerende oplossing te zijn. Dit geldt ook voor het uitschakelen van .htaccess, maar dit zien we niet veel gebruikers doen, omdat .htaccess een van de redenen is waarom ze überhaupt voor de server kiezen.

Nginx maakt gebruik van asynchrone, niet-blokkerende gebeurtenis-gestuurde architectuur.

Het verschil: in de wereld van Linux/Unix voeren processen programma’s uit.

Threads zijn een onderdeel van deze processen en binnen de uitvoering van een proces is er dus ruimte voor meerdere threads. Zie dit als meerdere tabbladen in een browservenster. Op deze manier kan een programma gebruik maken van meerdere CPU’s en multi-core en kan deze multi-thread CPU’s gebruiken om sneller processen uit te voeren. Hier kan je lezen hoe Linus Torvalds de verschillen uitlegt.

Kortom, Apache gebruikt voor elke verbinding een nieuw proces (en met worker mpm gebruikt het threads). Wanneer verkeer toeneemt, kan dit voor problemen zorgen.

Het is alsof je voor elk nieuw proces of het aanmaken van een thread een aparte computer of een nieuw programma moet opstarten. Zelfs op de snelste computers kost dit tijd. Websites moeten tegenwoordig honderden verzoeken afhandelen per pageload. Al met al telt dit natuurlijk op.

Wat optimalisatie betreft gaat event mpm iets verder, maar sommige tests laten zien dat het Nginx niet kan verslaan. Helemaal als we het hebben over statische bestanden, waarbij Nginx bijna twee keer zoveel verzoeken kan behandelen als Apache.

Nginx werkt het liefst met een workerproces per CPU/core. Het verschil met Nginx-werkprocessen is dat elke worker honderdduizenden binnenkomende netwerkverbindingen kan verwerken. Het is dus niet nodig om voor elke verbinding nieuwe threads of processen te maken.

Dit is de reden waarom grote Content Delivery Networks, zoals Cloudflare, MaxCDN en onze partner KeyCDN — of websites als Netflix — cruciaal achten voor het goed leveren van hun content.

De lijst met bedrijven die profiteren van Nginx is te lang om hier te plaatsen, maar we willen nog wel even melden dat ook Automattic, het bedrijf achter WordPress.com, gebruikmaakt van Nginx.

Voor WordPress.com converteerde Automattic in 2008 al hun load-balancers naar Nginx (je kan er hier meer over lezen) en migreerde hun serverstack volledig naar Nginx.

Hoe het er in de praktijk uitziet

Als je wil zien van een site welke server deze gebruikt, kan je deze meestal in de HTTP-responsheader vinden. Dit betekent dat je met de rechtermuisknop op een website wil klikken > Inspect, in de developer tools kiezen we het netwerkpaneel en laden we de site opnieuw. Hier vind je alle bronnen die de site laadt. Als je een bepaalde bron en zijn Headers-tab kiest, dan zie je meestal de serverinformatie. Als de website CDN gebruikt, dan zie je waarschijnlijk iets van Cloudflare in de serverregel of iets als Varnish als de website een HTTP-accelerator gebruikt.

Dit is een voorbeeld van een WordPress-website die gebruikmaakt van een typisch shared hosting met cPanel, Apache en PHP:

Dit is een website op Nginx:

Aan de linkerkant, als we deze uitbreiden, kunnen we ook zien hoe lang het kost om elke bron te laden en de impact hiervan op de totale laadtijd van de pagina.

Samenvatting

In dit artikel schreef ik over de verschillen tussen Nginx en Apache en tussen hun onderliggende architectuur en hoe dit laatste bijdroeg aan de enorme groei en aandacht die het platform als serverplatform kreeg. Dit zijn de belangrijkste eigenschappen die het een voorsprong geven op de prestaties in onze resource-hongerige industrie.

Natuurlijk heeft niet elke gebruiker dezelfde prioriteiten en biedt Apache tools aan als Lighttpd, ISS, LiteSpeed en Caddy wat mogelijk goede oplossingen zijn.

Bij Kinsta gebruiken we Nginx als onderdeel van onze prestatie-geoptimaliseerde hosting voor WordPress en WooCommerce. Elke WordPress-site is gehuisvest in zijn eigen geïsoleerde container, die alle benodigde softwarebronnen bevat om deze zo soepel mogelijk te draaien (Nginx, Linux, PHP, MySQL). De bronnen zijn 100% privé en worden niet gedeeld met andere sites.

Zorg ervoor dat je Nginx en al onze premium add-ons bekijkt. Je kunt ook onze diensten managed WordPress hosting, Application Hosting en Database Hosting bekijken voor meer hostingopties.

Tonino Jankov

Tonino is een ondernemer, Linux & OSS enthousiasteling, developer en tech-educator. Hij heeft meer dan tien jaar ervaring in development en is al meer dan 3 jaar actief in de blockchain-wereld. Als hij niet aan het coderen is, schrijft hij voor SitePoint en Alibaba Cloud, kijkt hij de nieuwste fictie op Netflix en verkent hij nieuwe reisbestemmingen.

• Twitter