NGINX vs. Apache: Hoe Kies je de Beste Webserver

Stel je dit voor: je zoekt naar nieuwe sneakers, je vindt een goede aanbieding en besluit om het op de website te bekijken.

Je wacht 10 seconden… 20 seconden… en de site laadt maar niet. Je bent het wachten zat, dus je gaat naar een andere site. Dit is waarschijnlijk wat er gebeurd is: de sneaker website heeft waarschijnlijk veel tijd en geld besteed aan flitsende afbeeldingen en strakke ontwerpen, maar dat is allemaal voor niets als het eeuwig duurt om te laden.

Het internet staat vol met trage websites.

De gemiddelde mobiele landingspagina doet er 22 seconden over om te laden, en dat is verschrikkelijk voor de business.

Een studie van Portent heeft aangetoond dat een site die in minder dan één seconde laadt een drievoudig hoger conversiepercentage heeft dan een site die er vijf seconden over doet om te laden.

Nu, wat heeft dit te maken met onze vergelijking tussen NGINX en Apache?

Een belangrijke factor die de snelheid van je site beïnvloedt, is je webserver — de software die je pagina’s aan bezoekers levert.

Apache en NGINX zijn twee van de meest prominente webservers die er zijn.

Vanaf juli 2024 meldt w3techs dat NGINX meer dan 34% van de websites ondersteunt, terwijl Apache 29,4% ondersteunt.

Maakt dat NGINX de duidelijke winnaar? Nog niet.

Web servers werken verschillend, afhankelijk van het gebruiksscenario. In deze gids bekijken we de verschillen tussen Apache en NGINX en leggen we uit waar je op moet letten bij het kiezen van een server.

Laten we beginnen.

Wat Zijn Webservers?

Web servers zijn softwaretoepassingen die draaien op een fysieke server en binnenkomende gebruikersverzoeken afhandelen.

Wanneer je een URL zoals “google.com” intypt, stuurt je browser een verzoek naar de webserver, die de bestanden opslaat die nodig zijn om de website te laten werken.

De server stuurt vervolgens de juiste inhoud terug, of dat nu HTML, CSS, JavaScript, afbeeldingen of een ander type is.

Webservers voeren veel belangrijke taken uit achter de schermen:

• Het beheren van HTTP-verbindingen en -verzoeken
• Verzoeken routeren naar de juiste backend applicatie indien nodig (zoals PHP, Python, of Ruby on Rails)
• Bestanden lezen en schrijven vanaf schijf om statische middelen te leveren
• Handhaven van beveiligingsbeleid
• Inhoud comprimeren voor snellere transmissie
• Verzoeken loggen voor analyse

Nu we hebben besproken hoe web servers werken, laten we kijken hoe NGINX en Apache deze taken aanpakken.

Wat Is Apache?

Apache HTTP Server, vaak gewoon Apache genoemd, is een populaire open-source webserver-software gecreëerd door Robert McCool en uitgebracht in 1995. Het is gebaseerd op de NCSA HTTPd-server.

De Apache Software Foundation, een non-profitorganisatie die opensource-softwareprojecten ondersteunt, heeft deze ontwikkeld en onderhoudt deze nog steeds.

Apache was vele jaren de meest gebruikte webserver ter wereld en ondersteunde veel websites. In feite speelde het een belangrijke rol in de groei van het wereldwijde web in zijn begindagen.

Enkele van de belangrijkste kenmerken en voordelen van Apache zijn:

• Modulaire Architectuur: De functionaliteit kan worden uitgebreid met modules voor verschillende functies en talen.
• Werkt Op Verschillende Besturingssystemen: Apache is ontworpen om platformonafhankelijk te zijn om je webserver te hosten op elk besturingssysteem, inclusief Linux, Windows en macOS.
• Uitgebreide Documentatie en Een Grote Gemeenschap: Helpt gebruikers en ontwikkelaars problemen op te lossen en betere oplossingen te ontwikkelen terwijl ze samenwerken.
• Flexibele Configuratie: De .htaccess bestanden kunnen directory-specifieke configuratiewijzigingen voor gebruikers vergemakkelijken.
• Beveiligingsfuncties: Apache heeft redelijk goede beveiliging vanwege zijn open-source aard en regelmatige updates om kwetsbaarheden en bugs te verhelpen.

Dat gezegd hebbende, Apache heeft een paar beperkingen:

• Hoger geheugengebruik: Het gebruikt meer geheugen dan NGINX, vooral bij het afhandelen van meerdere gelijktijdige verbindingen.
• Langzamer onder zware belasting: Het kan langzamer zijn dan NGINX bij het serveren van statische bestanden, vooral onder zware belasting.
• Uitdagend voor ontwikkelaars om te ontwikkelen en te onderhouden: In de loop der jaren heeft de groeiende complexiteit van de codebasis het moeilijker gemaakt om te bouwen en te onderhouden.

Wat Is NGINX?

NGINX (uitgesproken als “Engine X”) is een gratis, open-source, hoogwaardige webserver-software die voor het eerst werd uitgebracht in 2004. Het is gecreëerd door Igor Sysoev, een Russische software-engineer, om het probleem op te lossen van het gelijktijdig omgaan met veel gebruikers die een website bezoeken, wat een uitdaging was voor andere webservers zoals Apache.

Sysoev’s werk aan NGINX begon in 2002. Hij wilde het “C10k-probleem” aanpakken — het afhandelen van 10.000 gelijktijdige verbindingen.

Zijn visie was die van een snelle, stabiele en schaalbare server. Deze focus op prestaties maakt NGINX uitzonderlijk goed in het serveren van statische inhoud zoals HTML-pagina’s, afbeeldingen en CSS-bestanden.

Naast de snelheid blinkt NGINX uit als een reverse proxy. Het ontvangt gebruikersverzoeken en leidt deze intelligent door naar andere servers, zoals Apache of webtoepassingen, wat de benutting van bronnen optimaliseert.

Enkele van de belangrijkste voordelen van NGINX zijn:

• Gelijktijdige afhandeling: NGINX kan veel gebruikers tegelijkertijd aan zonder excessief geheugen of CPU vermogen te eisen.
• Makkelijk op te zetten en te configureren: NGINX heeft een eenvoudig en intuïtief configuratiebestandsformaat dat gebruikers helpt de webserver gemakkelijk te configureren naar hun gebruikssituatie.
• Verschillende prestatiekenmerken: NGINX heeft veel ingebouwde functies voor load balancing, caching, en het beveiligen van websites met SSL/TLS encryptie.
• Ondersteunt IMAP en POP3: NGINX fungeert ook als een mail proxyserver, met ondersteuning voor protocollen zoals IMAP en POP3.

Echter zijn er enkele nadelen aan het gebruik van NGINX:

• Standaardinstellingen zijn niet optimaal: De standaard load-balancing algoritmen presteren mogelijk niet altijd optimaal in elke situatie.
• Geen ingebouwde taalcompilers: Er is geen native ondersteuning voor het genereren van dynamische websites met server-side talen zoals PHP of Python. Desondanks kun je dit omzeilen met een extensie van derden.

Apache vs. NGINX: Wat Zijn de Verschillen?

Apache was ooit de topkeuze als webserver. Echter, NGINX nam snel het marktaandeel over en is nu populair bij veel websites met veel verkeer.

Als je van plan bent te werken met dedicated hosting, is het kiezen van de juiste webserver een belangrijke beslissing.

Dus, wat onderscheidt deze twee van elkaar?

Laten we eens nader bekijken.

Details	Apache HTTP Server	NGINX
Opgericht	1995	2004
Licentievoorwaarden	Apache License 2.0	2-clause BSD-licentie
Compatibiliteit met besturingssystemen	Windows, Linux, macOS, Unix-gebaseerde systemen	Windows, Linux, macOS, Unix-gebaseerde systemen
WebSocket-protocolondersteuning	Ja	Ja (geïntroduceerd in versie 1.3.13)
Ondersteuning voor reverse proxy	Ja	Ja
Configuratie van virtuele hosts	Ondersteund	Ondersteund
Caching	Beschikbaar via modules	Ingebouwd in de kern
Resourceverbruik (geheugen)	Hoog	Laag
Opzet en configuratieformaat	Tekstgebaseerd	Tekstgebaseerd (eenvoudigere syntax)
Beveiligingsfuncties	mod_security-ondersteuning biedt flexibele regelconfiguratie en toegangscontrole	Geavanceerde filtering, rate limiting, ingebouwde ondersteuning voor DDoS-mitigatie, en SSL/TLS-prestaties
Ondersteuning voor versleutelde communicatie (SSL/TLS)	Ondersteund	Ondersteund
Verwerking van gelijktijdige verbindingen	Goed	Zeer efficiënt
Schaalbaarheidsprestaties	Goed	Uitstekend
Functionaliteit voor lastverdeling	Bereikbaar met modules	Ingebouwde functie
Algehele prestaties en snelheid	Voldoende	Twee keer sneller dan Apache

Architectuur en Gelijktijdigheid

Een van de belangrijkste verschillen tussen NGINX en Apache is hoe ze binnenkomende verzoeken intern verwerken.

Dit heeft een aanzienlijke invloed op hun prestaties en efficiëntie van middelen.

Apache’s Procesgebaseerde Architectuur

Apache volgt een procesgebaseerd model en start een nieuwe thread of proces voor elke binnenkomende aanvraag.

Deze processen of threads worden beheerd door Multi-Processing Modules (MPMs):

• Prefork MPM: Het oorspronkelijke Apache-model. Elk proces heeft een enkele thread en hanteert één verbinding tegelijk. Het is eenvoudig, maar kan geheugenintensief zijn.
• Worker MPM: Gebruikt meerdere threads per proces, elk verwerkt een enkele verbinding. Het is beter dan prefork voor geheugen, maar zwaar verkeer en bronintensieve verzoeken kunnen nog steeds de CPU belasten, wat leidt tot prestatieproblemen.
• Event MPM: Vergelijkbaar met de worker MPM maar geoptimaliseerd voor keep-alive verbindingen (apparaten die niet van de server kunnen worden losgekoppeld). Echter, het is nog steeds niet volledig asynchroon.

Dit zijn allemaal goede modules, maar ze hebben één groot nadeel: Apache moet nieuwe processen of threads aanmaken voor elke binnenkomende verbinding en deze vernietigen als ze klaar zijn. Het probeert dit te beheren door van tevoren enkele inactieve processen vooraf te maken.

Echter, als meerdere mensen tegelijkertijd willen verbinden met de site, kan Apache zijn bestaande pool overschrijden, en dan moet het snel meer processen aanmaken. Dit kost tijd en verbruikt geheugen.

Dit model werkt perfect voor websites met laag tot gemiddeld verkeer. Zelfs dan kan Apache beginnen met het belasten van sites met veel gelijktijdige verbindingen.

Al deze afzonderlijke processen zijn niet super efficiënt. Zelfs met de event MPM kan Apache niet volledig ontsnappen aan het model van één thread per verbinding.

NGINX’s Event-Driven Architectuur

NGINX hanteert een heel andere aanpak. In plaats van afzonderlijke processen of threads voor elke verbinding, gebruikt NGINX een asynchrone, gebeurtenisgestuurde architectuur.

Zo werkt het: 

• NGINX heeft een hoofdproces (meestal één per CPU-kern) dat verschillende werkprocessen beheert. Elk werkproces kan duizenden gelijktijdige verbindingen aan. Er is geen noodzaak voor werkprocessen om nieuwe threads te starten of elke aanvraag naar een specifiek proces te routeren.
• In plaats daarvan hebben de werkers een event loop waar ze efficiënt nieuwe gebeurtenissen op bestaande verbindingen in de gaten houden via mechanismen van het besturingssysteem, zoals kqueue of epoll. Dit stelt hen in staat om meerdere verbindingen binnen één thread te jongleren. Wanneer er een gebeurtenis plaatsvindt, zoals een nieuwe aanvraag die binnenkomt of een backend server die reageert, verdeelt NGINX dit snel naar een vrije plek in de werker.
• Dit is veel efficiënter dan het model van Apache. NGINX kan een massaal aantal aanvragen verwerken met een kleine geheugenfootprint. Het schaalt ongelooflijk goed, wat de reden is waarom het gebruikt wordt voor veel van de drukste sites op het web.

Het nadeel is dat NGINX geen code-interpretators kan integreren zoals Apache dat doet.

Dus, wanneer je PHP of Python code wilt uitvoeren, stuurt NGINX verzoeken naar een afzonderlijke FastCGI procesmanager zoals php-fpm. Dit proces voert de code uit en vertaalt het naar iets dat de browser van de gebruiker kan begrijpen.

Aan de andere kant kan Apache talen zoals PHP, Perl en Python binnen zijn processen uitvoeren.

Omdat NGINX niet kan, kan het config bestand wat complexer worden.

De prestatievoordelen wegen echter meestal op tegen het ongemak.

Prestatie

NGINX staat bekend om de hoge prestaties bij het serveren van statische bestanden zoals HTML-pagina’s, afbeeldingen, CSS en JavaScript.

De event-gestuurde architectuur helpt, maar NGINX heeft ook nog andere trucs.

Ten eerste hoeft NGINX, in tegenstelling tot Apache, niet voor elke aanvraag de cache te doorlopen en de schijf te raken. Het kan bestanden rechtstreeks vanaf de schijf aanbieden. Bovendien elimineert NGINX de overhead die gepaard gaat met het controleren van rechten en het vergrendelen van bestanden.

Apache heeft deze problemen omdat elke aanvraag een proces is, en als één proces iets wijzigt, kan het andere proces niet tegelijkertijd hetzelfde bestand gebruiken.

Hoewel kleinere websites deze knelpunt niet zullen merken vanwege de snelheid waarmee dingen achter de schermen worden verwerkt, zal een grote site met een paar duizend verzoeken per seconde beginnen te merken dat deze problemen de gebruikerservaring vertragen.

NGINX heeft ook een ingebouwde bestandscache. Bij het eerste verzoek om een bestand, leest NGINX het van de schijf en plaatst het in zijn cache. Toekomstige verzoeken voor dat bestand kunnen razendsnel rechtstreeks uit het geheugen worden geserveerd zonder de schijf aan te raken. Het maakt ook automatisch de gecachte gegevens ongeldig als het bestand op de schijf wijzigt.

Deze optimalisaties tellen op. In benchmarks kan NGINX vaak statische bestanden ongeveer drie keer sneller serveren dan Apache, vooral als het aantal gelijktijdige verzoeken toeneemt.

Een bonus: dit kan je ook helpen om je kernweb vitals te verbeteren, waardoor je een kleine voorsprong op Google krijgt.

Apache is ook niet traag. Je moet gewoon tijd besteden aan het fijnafstemmen ervan zodat het precies goed werkt. Het is ook in staat om statische bestanden heel snel te bedienen.

Maar NGINX is de juiste keuze als je direct een performante webserver wilt.

Configuratie en Syntax

NGINX en Apache hebben verschillende configuratiefilosofieën.

Apache is beroemd om zijn uitgebreide configuratiemogelijkheden. Naast de apache2.conf moet je jouw regels en configuraties toevoegen aan het .htaccess bestand.

De configuratiebestanden gebruiken een XML-achtige syntaxis en bieden ongelooflijke flexibiliteit. Apache heeft een enorme lijst met richtlijnen die je kunt gebruiken om elk aspect van het servergedrag aan te passen.

Je kunt configuratie opties wereldwijd instellen of ze overschrijven voor specifieke mappen of virtuele hosts.

De echte kracht van Apache komt voort uit zijn uitgestrekte ecosysteem van modules. Een enorme reeks officiële en externe Apache-modules stelt je in staat om alles te doen, van URL-omleiding tot beveiligingsfiltering tot geavanceerde caching. Om een module te gebruiken, laad je deze in je Apache-configuratie.

De keerzijde is dat de Apache-configuratie snel ingewikkeld kan worden, vooral voor geavanceerde instellingen. Directieven kunnen elkaar overschrijven in lastige overervingketens. Configuratie-opties zijn vaak verdeeld over meerdere bestanden in verschillende submappen van de hoofdmap config. Het is super flexibel, maar het kost wat tijd om te beheersen.

De configuratie van NGINX streeft daarentegen naar eenvoud en leesbaarheid. Hier is geen .htaccess-bestand. Je configureert de sites gewoon in je NGINX.conf samen met de map sites-enabled, en je bent klaar om te starten.

De syntaxis leent stijlelementen van gangbare programmeertalen. Het is nog steeds krachtig, maar niet zo uitgebreid als Apache.

In plaats van modules heeft NGINX een kleinere set van kernrichtlijnen en functies die standaard geïntegreerd zijn. Al je opties voor een bepaalde functie staan meestal samen in één blok (ingesloten in accolades { }).

Sommige geavanceerde functies zoals load balancing en caching worden geconfigureerd in het hoofd NGINX.conf, niet gescheiden in bijbestanden.

Het resultaat is dat NGINX-configuratiebestanden doorgaans compacter zijn en gemakkelijker te lezen en te configureren dan de omvangrijke Apache-bestanden, maar je kunt er nog steeds veel mee doen.

Beveiliging

NGINX en Apache zijn open-source projecten met grote, actieve gemeenschappen van ontwikkelaars die voortdurend werken aan het identificeren en patchen van kwetsbaarheden. Ze ontvangen beiden regelmatig beveiligingsupdates en hebben een goede staat van dienst wat betreft het snel aanpakken van problemen.

Desalniettemin zijn er enkele verschillen in hoe ze beveiliging benaderen.

Hier zijn een paar belangrijke punten om te overwegen:

• Modulariteit: De modulaire architectuur van Apache betekent dat je alleen de functies hoeft te activeren die je gebruikt, waardoor het aanvalsoppervlak wordt geminimaliseerd. Bij NGINX zijn veel standaardfuncties rechtstreeks in de kern ingebouwd, wat volgens sommigen het minder flexibel maakt vanuit een beveiligingsperspectief.
• Verzoekfiltering: NGINX heeft een krachtige ingebouwde verzoekfilteringsengine die kan helpen veelvoorkomende webaanvallen te blokkeren zoals SQL-injectie en cross-site scripting (XSS). Apache heeft vergelijkbare mogelijkheden via modules zoals mod_security.
• SSL/TLS-configuratie: Beide servers ondersteunen SSL/TLS voor versleutelde verbindingen, maar NGINX wordt vaak als eenvoudiger te configureren beschouwd. Het heeft duidelijkere documentatie en veiligere standaardinstellingen uit de doos.
• Procesisolatie: Het gebruik van een enkel hoofdproces met meerdere werkprocessen door NGINX kan helpen problematische gebieden te isoleren. Apache’s prefork en worker MPMs kunnen vergelijkbare procesniveau-isolatie bieden, maar ten koste van het gebruik van meer middelen.
• DDoS-mitigatie: De op gebeurtenissen gebaseerde architectuur van NGINX en de efficiënte afhandeling van gelijktijdige verbindingen maken het een populaire keuze voor het mitigeren van kleine tot middelgrote DDoS-aanvallen. Een paar extra modules en afstemming kunnen ook Apache resistent maken tegen DDoS-aanvallen.

Dynamische Inhoud, Modules en Ecosysteem

Apache is al lange tijd de voorkeursoptie voor het aanbieden van dynamische inhoud omdat het server-side talen gemakkelijk integreert. Met de prefork- en worker-MPMs kun je ondersteuning voor talen zoals PHP, Python en Perl direct in de Apache-binair compileren.

Apache zal dan een interpreter uitvoeren binnen elk van zijn werkprocessen. Dit is mooi en eenvoudig — Apache kan verzoeken voor .php bestanden doorgeven aan zijn ingebouwde PHP-interpreter en gerenderde output terugkrijgen.

NGINX heeft geen ingebouwde ondersteuning voor server-side talen. Je hebt een aparte dienst zoals php-fpm nodig die de taalinterpreter uitvoert om PHP, Python, of Ruby on Rails met NGINX te draaien. NGINX ontvangt verzoeken en stuurt deze door naar de backend, die de code verwerkt en een reactie terugstuurt.

Dit vereist iets meer werk om in te stellen dan de alles-in-één aanpak van Apache. Maar het past wel bij de filosofie van NGINX om één ding te doen (verzoeken bedienen) — en dat goed te doen.

Wat betreft andere functies, NGINX wordt geleverd met een solide kern van nuttige functies zoals load balancing, proxying, caching, snelheidsbeperking, compressie en SSL-beëindiging. Maar het haalt niet de ongelooflijke breedte van het module-ecosysteem van Apache. Met Apache heb je modules voor authenticatieschema’s, inhoudsfiltering, ingesloten scripttalen en meer.

Niet elk van deze is uniek. NGINX kan veel van dezelfde taken uitvoeren, alleen op andere manieren. Echter, de modulebibliotheek van Apache is vrij uitgebreid.

Als er een heel specifieke functionaliteit is die je nodig hebt, kan Apache hier de overhand hebben.

Toch is de functionaliteit van NGINX robuust genoeg voor de meeste gangbare webserveerbehoeften.

Praktisch Gebruik, Prestaties en Gemeenschap

De populariteit van NGINX is de afgelopen tien jaar gestegen.

Vanaf 2022 ondersteunt het meer dan 34% van alle websites wereldwijd, vergeleken met ongeveer 29% van Apache.

Eén ding moet je in gedachten houden: je zult het verschil tussen deze webservers niet merken tenzij je een grote website hebt of een echt kleine server.

Stel je voor dat je Apache’s uitgebreide configuratieopties en alles-in-één-aanpak voor dynamische inhoud waardeert. De Apache-documenten behoren tot de beste en de gemeenschap is enorm als je ooit hulp nodig hebt.

NGINX is mogelijk beter als je maximale gelijktijdigheid najaagt of een enorme site bouwt. De architectuur is wat meer toekomstbestendig en gebouwd voor schaalvergroting. En de NGINX-gemeenschap is snel gegroeid. De documentatie is ook solide; je kunt veel handleidingen en ondersteuning vinden.

Apache vs. NGINX: Welke Is Geschikt Voor Jou?

Er is geen pasklare oplossing voor het debat tussen NGINX en Apache. Desondanks zijn hier enkele goede vuistregels om je te helpen bij het maken van de beslissing.

NGINX is beter als:

• Je hebt een site met erg veel verkeer.
• Je moet snel een hoop statische bestanden beschikbaar stellen.
• Je bouwt een microservicesarchitectuur.
• Je houdt van een meer gestroomlijnde configuratiestijl.
• Je gebruikt containers of Cloud Hosting waarbij elke ons geheugen telt.

Apache is beter als:

• Je hebt diepe compatibiliteit met alleen Apache-functies zoals .htaccess nodig.
• Je wilt modules voor zeer specifieke functionaliteit.
• Je moet oudere web-apps draaien die gebouwd zijn voor Apache en mod_php.
• Je bent gewoon erg gesteld op het configuratiesysteem van Apache.
• Jouw server is voornamelijk een ontwikkelbox, en prestaties zijn minder kritisch.

Er is geen regel die zegt dat je er één moet kiezen.

NGINX voor Apache draaien als een omgekeerde proxy is heel gebruikelijk. Hiermee kun je de onverslaanbare statische bestandsservering en gelijktijdige verwerking van NGINX combineren met de rijke ondersteuning van dynamische talen van Apache op de backend — het beste van beide werelden.

Afronden

Apache en NGINX zijn beide geweldig, dus het kiezen van een van beide hangt vooral af van wat het beste bij je behoeften past.

Onthoud, zelfs de krachtigste webserver is slechts één onderdeel van de machine. Dus, als de site traag aanvoelt, hoeft de software of hardware van de webserver niet per se het eerste te zijn wat je optimaliseert.

Intelligentere caching, databasetuning, code-optimalisatie en solide onderliggende hardware kunnen allemaal helpen om je stack sneller te maken dan urenlang te sleutelen aan NGINX of Apache.

Als je een server nodig hebt om mee te experimenteren, probeer dan de beheerde VPS van DreamHost. Met een VPS kun je kiezen welke software je installeert, hoe de server op verzoeken moet reageren, en meer. Bovendien, met de flexibiliteit van een VPS, kun je meerdere websites op één server hosten en de middelen dienovereenkomstig verdelen.

Daarnaast zijn nu alle DreamPress plannen voorzien van NGINX.

De enige manier om de ideale opstelling te vinden is door te experimenteren. Zet een VPS op, installeer NGINX en Apache, en kijk wat het beste voor je werkt!