Dedicated server optimalisatie voor websites met veel verkeer

Dedicated server optimalisatie voor websites met veel verkeer betekent dat je processor, RAM, opslag, netwerk, webserver, database, cache, beveiliging en monitoring als één geheel afstemt. Het doel is dat je website ook bij plotselinge pieken snel, stabiel en veilig blijft werken. In de praktijk draait het om kortere responstijden, meer verzoeken per seconde zonder fouten, minder verspilling van resources en het vroegtijdig signaleren van problemen voordat bezoekers ze merken. Voor webshops, nieuwsplatforms, SaaS-omgevingen, gamingcommunities, forums en campagnesites met veel gelijktijdige bezoekers biedt een goed ingerichte dedicated server doorgaans consistenter presterende hosting, meer controle en beter voorspelbare kosten dan gedeelde infrastructuur.

In deze gids behandelen we dedicated server optimalisatie niet alleen met algemene tips, maar met controlepunten die je in echte productieomgevingen kunt toepassen. Deze Hostragons-blog gaat in op serverkeuze, Linux-instellingen, optimalisatie van NGINX of Apache, PHP-FPM, MySQL- of MariaDB-configuratie, Redis-cache, CDN, beveiliging, back-ups en monitoring. Richt je een nieuwe serveromgeving in, dan is het verstandig om de opties voor Huurserver mee te nemen. Kom je vanuit een kleinere omgeving, bekijk dan ook de gidsen rond VPS Server. Voor veilige verbindingen hoort bovendien SSL certificaten standaard in je planning thuis.

Wat betekent veel verkeer voor een dedicated server?

Veel verkeer gaat niet alleen over het aantal bezoekers per dag. Belangrijker zijn het aantal gelijktijdige gebruikers, het aantal requests per seconde, de hoeveelheid dynamische verwerking, het downloadvolume, de kosten van databasequeries en piekbelasting tijdens campagnes. Een blog met vooral statische content en 200.000 bezoekers per dag kan met goede caching relatief weinig resources gebruiken. Een webshop met 30.000 bezoekers per dag kan daarentegen veel zwaarder zijn door winkelwagens, betalingen, voorraadcontrole, klantaccounts en zoekopdrachten.

Bij de eerste beoordeling moet je minimaal de volgende metrics meten:

• Gelijktijdige gebruikers: Het aantal actieve sessies op hetzelfde moment. Bij campagnesites kan dit binnen minuten vijf tot tien keer hoger worden.
• RPS: Het aantal HTTP-verzoeken per seconde. Meet homepage, productpagina’s, API-verkeer en statische bestanden apart.
• TTFB: Time to First Byte, oftewel de tijd tot de eerste byte. Onder 200 ms is uitstekend, 200-500 ms is vaak acceptabel en boven 1 seconde is een duidelijk optimalisatiesignaal.
• CPU load: Interpreteer dit altijd ten opzichte van het aantal cores. Op een server met 8 cores kan een load van 8 langdurig de bovengrens zijn; 12 of hoger kan een alarmsignaal zijn.
• RAM-gebruik: Vrij geheugen alleen zegt weinig, omdat Linux geheugen gebruikt voor cache. Het echte risico begint wanneer swap structureel wordt aangesproken.
• Disk IOPS en latency: Vooral bij database-intensieve sites en veel logging maken NVMe-schijven een groot verschil.
• Foutpercentage: 5xx-antwoorden, time-outs en database connection errors worden vaak pas goed zichtbaar onder hoge belasting.

De juiste dedicated server kiezen: optimalisatie begint bij hardware

Software-instellingen kunnen veel verbeteren, maar verkeerde hardware blijft een harde bottleneck. Bij het kiezen van een dedicated server voor een website met veel verkeer is alleen kijken naar het aantal CPU-cores niet genoeg. Je moet eerst het karakter van de workload begrijpen: is de applicatie vooral CPU-intensief, RAM-intensief, afhankelijk van snelle disk I/O of juist zwaar op netwerkverkeer?

CPU: aantal cores of kloksnelheid?

Voor PHP, Node.js, Python en databaseverwerking is CPU-performance cruciaal. Als het verkeer sterk parallel is en veel gelijktijdige requests bevat, helpen extra cores. Voor snelle afhandeling van individuele requests is een hoge kloksnelheid juist belangrijk. Bij dynamische PHP-systemen zoals WordPress met WooCommerce leveren 8 tot 16 snelle cores in veel scenario’s een goede balans op. Heb je veel videoconversie, rapportages, imports of zware cronjobs, dan is opschalen in core-aantal vaak logischer.

RAM: investeren in cache en ademruimte

Bij veel verkeer is RAM niet alleen nodig om de applicatie te laten draaien. Het wordt ook gebruikt voor databasebuffers, Redis-cache, PHP-FPM workers en de diskcache van het besturingssysteem. 16 GB RAM kan een instapniveau zijn; voor drukke webshops, nieuwsportalen of grote ledenomgevingen zijn 32 GB, 64 GB of meer vaak veiliger. Zie je continu swapgebruik, onderzoek dan eerst geheugenlekken en worker-instellingen. Pas daarna is het verstandig om een RAM-upgrade te plannen.

Opslag: waarom NVMe zo belangrijk is

SSD’s waren lange tijd de standaard voor snelle hosting, maar bij database-intensieve websites met veel verkeer bieden NVMe-schijven lagere latency en hogere IOPS. Vooral MySQL InnoDB, Elasticsearch, logverwerking en scenario’s met veel schrijfacties profiteren hiervan. Als database en webapplicatie op dezelfde dedicated server draaien, kan een overstap naar NVMe in veel gevallen zichtbaarder resultaat geven dan alleen een CPU-upgrade.

Netwerk: bandbreedte en dataverkeer

Voor websites met veel afbeeldingen, video’s, softwaredownloads of mediabestanden wordt netwerkcapaciteit snel kritiek. Een 1 Gbps-poort is voor veel websites voldoende, maar de echte behoefte bepaal je aan de hand van maandelijks dataverkeer en piekbelasting tijdens drukke uren. Een CDN kan hier de origin-server sterk ontlasten. Wil je domein- en DNS-beheer centraal houden, neem dan ook Domeinquery en DNS beheer mee in je planning.

Een gelaagde aanpak voor dedicated server optimalisatie

Er bestaat geen magische instelling die alles oplost. Succesvolle dedicated server optimalisatie is gelaagd: besturingssysteem, webserver, applicatieruntime, database, cache, bestandsdistributie, beveiliging en monitoring moeten samen worden bekeken. De onderstaande tabel vat veelvoorkomende bottlenecks en passende oplossingen samen.

Instellingen op besturingssysteem- en kernelniveau

Op Linux-gebaseerde dedicated servers worden Ubuntu LTS, Debian, AlmaLinux en Rocky Linux vaak gekozen. Belangrijker dan de distributienaam is dat je een actuele, ondersteunde versie gebruikt die je team goed kan beheren. Na de eerste installatie moeten onnodige services worden uitgeschakeld, automatische beveiligingsupdates worden gepland en basislimieten van het systeem worden gecontroleerd.

Limieten voor file descriptors

Bij veel verkeer kan elke verbinding, elk bestand, elke socket en elke logactie tegen systeemlimieten aanlopen. Als NGINX of PHP-FPM veel gelijktijdige verbindingen verwerkt, moet de open file limit vaak omhoog. Standaardwaarden zoals 1024 zijn in drukke omgevingen meestal te laag; waarden van 65535 of hoger kunnen, afhankelijk van de servercapaciteit, passend zijn. Alleen de limiet verhogen is echter geen oplossing op zichzelf. De waarde moet aansluiten op worker- en connection-instellingen.

TCP en verbindingswachtrijen

Tijdens piekmomenten, bijvoorbeeld bij een kortingsactie of nieuwsdoorbraak, kunnen verbindingswachtrijen vollopen. Gebruikers krijgen dan fouten nog voordat de applicatie echt bereikt wordt. Parameters zoals somaxconn, tcp_max_syn_backlog en het poortbereik moeten worden ingesteld op basis van metingen. Gebruik liever geen willekeurige sysctl-snippets van internet, maar test instellingen met realistische loadtests. Een voorbeeld: een nieuwssite die 10.000 gelijktijdige verbindingen wil verwerken, moet webserver-workers, kernel backlog en upstream-connecties tegelijk plannen.

Webserver optimalisatie: NGINX, Apache en LiteSpeed

De webserver is de eerste laag die een gebruikersverzoek opvangt. NGINX blinkt uit bij veel gelijktijdige verbindingen dankzij zijn event-driven architectuur. Apache is populair door flexibiliteit en brede .htaccess-ondersteuning. LiteSpeed kan zeer sterk presteren bij WordPress-projecten, vooral in combinatie met LSCache. Welke software je ook kiest, het doel blijft hetzelfde: statische bestanden snel leveren, dynamische verzoeken efficiënt doorsturen naar de juiste upstream-laag en overbodige of schadelijke requests zo vroeg mogelijk stoppen.

Belangrijke instellingen voor NGINX

• worker_processes: Vaak is auto op basis van het aantal CPU-cores een goede keuze.
• worker_connections: Stem dit af op het verwachte aantal gelijktijdige verbindingen en de file descriptor-limieten.
• keepalive_timeout: Te lange waarden houden verbindingen onnodig bezet; te korte waarden veroorzaken extra reconnect-kosten. Een bereik van 10-30 seconden is in veel situaties gebalanceerd.
• gzip of Brotli: Verkleint HTML-, CSS-, JS- en JSON-uitvoer en verlaagt bandbreedtegebruik.
• static cache headers: Voeg langlopende cacheheaders toe voor afbeeldingen, fonts en JavaScript-bestanden.
• rate limiting: Beperkt bots, scrapers en schadelijke scanverzoeken.

Als je Apache gebruikt

Bij Apache is de keuze van MPM erg belangrijk. In combinatie met PHP-FPM is event MPM vaak efficiënter dan de oudere prefork-aanpak. .htaccess-bestanden worden bij elke request gelezen en kunnen daarom performance kosten. Verplaats regels waar mogelijk naar de hoofdconfiguratie. Beperk ook het aantal modules en schakel alles uit wat niet nodig is.

PHP-FPM en optimalisatie van de applicatielaag

Bij WordPress, Laravel, OpenCart, Magento en maatwerk-PHP-applicaties hebben PHP-FPM-instellingen directe invloed op performance. De meest voorkomende fout is het verhogen van pm.max_children zonder RAM-berekening. Als elke PHP-worker gemiddeld 80 MB gebruikt en er 8 GB voor PHP beschikbaar is, ligt de theoretische bovengrens rond de 100 workers. Maar database, Redis en het besturingssysteem hebben ook geheugen nodig. Kies daarom een realistische lagere waarde en meet onder echte belasting.

Gebruik van OPcache

OPcache bewaart gecompileerde PHP-bestanden in het geheugen en verlaagt daarmee CPU-verbruik. In productie moet opcache.enable actief zijn, moet opcache.memory_consumption passen bij de grootte van het project en moet er een betrouwbaar mechanisme zijn om cache te legen bij deployments. In grote WordPress- of Laravel-projecten zorgt een uitgeschakelde OPcache vaak voor onnodig hoge CPU-load.

Cronjobs en achtergrondprocessen

In systemen met veel verkeer horen rapportages, e-mailverzending, voorraadsynchronisatie en data-imports niet tijdens de gebruikersrequest te worden uitgevoerd. Gebruik queues en splits achtergrondwerkers af met Redis, RabbitMQ of een vergelijkbare oplossing. Zo reageren kritieke flows zoals checkout, betaling en login sneller en voorspelbaarder.

Database optimalisatie: MySQL en MariaDB

Bij veel drukbezochte websites zit de bottleneck in de database. Als CPU-gebruik op de server laag lijkt maar pagina’s toch traag zijn, kunnen trage queries, locks of slechte indexen de oorzaak zijn. De eerste stap is het inschakelen van de slow query log en het identificeren van de duurste queries. Een goede index toevoegen is vaak goedkoper en effectiever dan hardware uitbreiden.

InnoDB Buffer Pool

Op een server waar MySQL of MariaDB een grote rol speelt, zorgt de InnoDB buffer pool ervoor dat data in RAM kan blijven. Draait alleen de database op de server, dan kan 60-70 procent van het RAM aan de buffer pool worden toegewezen. Draaien webserver en database op dezelfde dedicated server, dan moet je voorzichtiger zijn. Op een server met 32 GB RAM kan, afhankelijk van applicatie- en cachebehoefte, 12-18 GB buffer pool een redelijke startwaarde zijn.

Index- en queryanalyse

De EXPLAIN-uitvoer laat zien of een query een volledige tabelscan doet. Productlijsten, categoriefilters, zoekfuncties, ledeninformatie en ordertabellen moeten regelmatig worden bekeken. In een ordertabel met 1 miljoen rijen kan een verkeerde index ervoor zorgen dat bij elke request honderdduizenden rijen worden gescand. Zodra het verkeer toeneemt, schieten CPU- en diskgebruik dan snel omhoog.

Wanneer moet je de database scheiden?

Eén dedicated server kan lange tijd genoeg zijn. Maar als CPU, RAM en disk I/O tegelijk onder druk staan, wordt het zinvol om de database naar een aparte server te verplaatsen. Bij veel leesverkeer kan een read replica helpen. Bij systemen met veel schrijfacties moeten applicatiearchitectuur, tabelontwerp en transacties apart worden beoordeeld.

Cache-strategie: de goedkoopste performancewinst

Cache is een van de optimalisatiegebieden met de hoogste opbrengst bij websites met veel verkeer. Het doel is eenvoudig: produceer dezelfde content niet opnieuw bij elke request. Een goede cache-strategie is gelaagd. Browsercache, CDN-cache, paginacache, objectcache en applicatieniveau-mechanismen voor queryresultaten moeten samen worden ontworpen.

Paginacache

Voor blogs, nieuwssites en zakelijke websites kan full-page caching de serverload drastisch verlagen. Een WordPress-pagina zonder cache start bij elke request PHP en MySQL op. Met cache kan NGINX vaak direct statische HTML teruggeven. Daarmee kan dezelfde hardware meerdere keren zoveel requests per seconde verwerken.

Redis of Memcached

Redis wordt vaak gebruikt voor sessies, objectcache, tijdelijke data en queueprocessen. In dynamische systemen zoals WooCommerce kunnen productdata, pagina’s buiten de winkelwagen, instellingen en veelgelezen queries met Redis worden versneld. Stel wel een duidelijke memory limit in en kies bewust een eviction policy. Anders kunnen bij vol geheugen onverwachte cacheverwijderingen ontstaan.

CDN en statische assets

Een CDN levert afbeeldingen, CSS, JS, fonts en soms cachebare HTML vanaf een locatie dichter bij de gebruiker. Daardoor dalen bandbreedtegebruik en requestbelasting op de origin dedicated server. Vooral websites die ook bezoekers buiten Nederland of België ontvangen, profiteren van lagere latency. Denk voor veilige HTTPS-configuratie aan SSL certificaten en combineer domeinbeheer waar nodig met Domeinoverdracht.

Optimalisatie van afbeeldingen, bestanden en front-end

Serveroptimalisatie bestaat niet alleen uit backend-instellingen. Grote afbeeldingen, overbodige JavaScript-bestanden en slechte cacheheaders kunnen zelfs een krachtige dedicated server traag doen aanvoelen. WebP- of AVIF-formaten, lazy loading, responsive images en het beperken van externe scripts hebben direct effect op laadtijd en dataverbruik.

Een praktisch voorbeeld: een webshop met 6 MB aan afbeeldingen op de homepage kan na omzetting naar WebP en correcte afbeeldingsformaten zakken naar ongeveer 1,8 MB totale paginagrootte. Voor mobiele bezoekers kan dat meerdere seconden schelen en het verlaagt tegelijk de hoeveelheid data die de server of CDN moet leveren.

Beveiligingsoptimalisatie: het verborgen onderdeel van performance

Bots, brute-forcepogingen, malafide scans en DDoS-achtig verkeer verbruiken serverresources. Daarom is beveiliging een vast onderdeel van performanceoptimalisatie. Als je website traag aanvoelt voor echte gebruikers, ligt de oorzaak niet altijd bij slechte queries. Vaak eet onnodig botverkeer ongemerkt capaciteit op.

Basischecklist voor beveiliging

• Schakel directe SSH-rootlogin uit en gebruik toegang op basis van sleutels.
• Een andere SSH-poort is op zichzelf geen beveiliging; combineer dit met fail2ban en IP-beperkingen.
• Activeer een WAF of application firewall.
• Bescherm adminpanelen met rate limiting en, waar mogelijk, IP-whitelisting.
• Voer updates regelmatig uit en verwijder ongebruikte pakketten.
• Maak HTTPS verplicht met Let’s Encrypt of commerciële SSL-certificaten.
• Bewaar back-ups versleuteld, op een aparte locatie en test het herstelproces regelmatig.

Bij het plannen van je beveiligingslaag is het logisch om ook onderwerpen zoals Webhosting Güvenliği, SSL certificaten en Zakelijke E-mail Beveiliging intern te koppelen. Dat versterkt niet alleen de veiligheid, maar ook de gebruikersreis op je website.

Monitoring, logging en alerts: je kunt niet optimaliseren wat je niet meet

Op een dedicated server met veel verkeer is monitoring geen luxe maar noodzaak. CPU, RAM, disk, netwerk, servicestatus, HTTP-statuscodes, queue-lengtes, databasequerytijden en de vervaldatum van SSL-certificaten moeten worden gevolgd. Tools zoals Prometheus, Grafana, Netdata, Zabbix of vergelijkbare oplossingen zijn hiervoor geschikt. Zelfs in eenvoudige setups zijn uptimebewaking en waarschuwingen via e-mail of chat essentieel.

Alarmdrempels die je moet volgen

• Geef een waarschuwing als CPU load gedurende 10 minuten boven 80 procent van het aantal cores uitkomt.
• Start onderzoek als swap na RAM-druk structureel boven 512 MB blijft.
• Stel een alarm in bij 80 procent diskgebruik; 90 procent moet als urgent worden behandeld.
• Controleer applicatie- en upstream-logs als het percentage 5xx-fouten boven 1 procent komt.
• Onderzoek cache, database en PHP-FPM als de gemiddelde TTFB boven 500 ms uitkomt.
• Maak 14 dagen vóór het verlopen van een SSL-certificaat automatisch een waarschuwing aan.

Ook logs moeten actief worden beheerd. Access logs, error logs, databaselogs en applicatielogs kunnen zonder beleid de schijf vullen. Gebruik logrotate-regels en stuur kritieke logs bij voorkeur door naar een centraal logsysteem.

Loadtesting en capaciteitsplanning

Optimalisaties moeten worden gevalideerd met realistische loadtests. ApacheBench is bruikbaar voor heel eenvoudige tests, maar tools zoals k6, JMeter en Locust maken realistischer gebruikersscenario’s mogelijk. Alleen de homepage testen is misleidend. Productzoekopdrachten, categoriefilters, login, toevoegen aan winkelwagen, stappen vóór betaling en API-calls moeten afzonderlijk worden gemeten.

Gebruik bij loadtests een datavolume dat lijkt op productie. Een testdatabase met 100 producten gedraagt zich anders dan een live database met 500.000 producten. Zorg er ook voor dat CDN-cache, botbescherming en database-indexen zo dicht mogelijk bij de live situatie liggen. Definieer doelen vooraf: bijvoorbeeld bij 2.000 gelijktijdige gebruikers moet de 95e percentiel responstijd onder 800 ms blijven en het foutpercentage onder 0,5 procent.

Stapsgewijze checklist voor dedicated server optimalisatie

De onderstaande volgorde is praktisch toepasbaar en verkleint de kans op fouten:

• 1. Meet de huidige situatie: Leg verkeer, RPS, TTFB, CPU, RAM, disk en database-metrics vast.
• 2. Bepaal de bottleneck: Is het probleem CPU, database, disk of netwerk? Beslis op basis van data, niet op gevoel.
• 3. Valideer de hardware: Controleer of CPU-cores, RAM, NVMe-opslag en poortsnelheid passen bij de workload.
• 4. Stel de webserver af: Optimaliseer workers, keepalive, compressie en cacheheaders in NGINX, Apache of LiteSpeed.
• 5. Optimaliseer de applicatieruntime: Controleer PHP-FPM, OPcache, Node.js process managers of de relevante runtime-instellingen.
• 6. Onderzoek de database: Activeer slow query logs, verbeter indexen en stel buffer pool en connection limits correct in.
• 7. Bouw de cachelaag: Ontwerp CDN, paginacache, Redis en browsercache als samenhangend geheel.
• 8. Verhard de beveiliging: Gebruik WAF, rate limiting, fail2ban, SSH-sleutels en regelmatige updates.
• 9. Richt monitoring en alerts in: Volg kritieke metrics in een dashboard en ontvang automatisch meldingen bij drempeloverschrijding.
• 10. Voer loadtests uit: Valideer wijzigingen met realistische scenario’s en documenteer de resultaten.

Wanneer opschalen en wanneer moet de architectuur veranderen?

Niet elk performanceprobleem los je op met een grotere server. Als één query het hele systeem blokkeert, stelt hardware uitbreiden het probleem alleen uit. Maar als CPU-cores continu vol zitten, RAM gezond wordt gebruikt, queries geoptimaliseerd zijn en cache correct werkt, dan is overstappen naar een krachtigere dedicated server logisch. Dit heet verticaal schalen.

Horizontaal schalen betekent dat je de weblaag over meerdere servers verdeelt, een load balancer gebruikt, de database scheidt, read replicas toevoegt en statische bestanden via CDN of object storage aanbiedt. Voor grote e-commerce- en mediaprojecten is deze aanpak vaak duurzamer. Vergeet in een migratieplan geen DNS TTL-waarden, SSL-certificaten, sessiebeheer, bestandssynchronisatie en back-upprocessen.

Waar moet je op letten bij planning met Hostragons?

Een dedicated server kies je niet alleen voor het verkeer van vandaag, maar ook voor de groeidoelen van de komende 6 tot 12 maanden. Campagneperiodes, advertentiebudget, seizoensdrukte, SEO-groei en nieuwe functionaliteiten moeten onderdeel zijn van capaciteitsplanning. Terwijl je bij Hostragons passende resources voor Huurserver vergelijkt, kun je voor je domein Domeinquery meenemen, voor veilig verkeer SSL certificaten plannen en voor startende projecten de juiste route vanuit Webhosting bepalen.

Een goed geoptimaliseerde dedicated server zorgt voor snellere pagina’s, minder fouten, een veiliger platform en een betere gebruikerservaring. Ook voor SEO zijn snelheid, beschikbaarheid en stabiliteit sterke indirecte signalen. Zeker nu zoekmachines gebruikerservaring zwaarder meewegen, kunnen trage websites of sites met veel fouten organische zichtbaarheid verliezen.

Conclusie

Dedicated server optimalisatie voor websites met veel verkeer is geen eenmalige instelling, maar een doorlopende cyclus van meten, verbeteren, testen en monitoren. Begin met de juiste hardwarekeuze en bekijk daarna webserver, applicatie, database, cache, beveiliging en alerts als samenhangend systeem. Zo haal je veel meer rendement uit dezelfde infrastructuur. Wil je de huidige capaciteit van je server beoordelen of een omgeving kiezen die past bij je groeiplannen, dan kun je de dedicated server opties van Hostragons bekijken en een soepele migratie of opschaling plannen.

Veelgestelde vragen

Hoe lang duurt dedicated server optimalisatie?

Basismetingen en eerste optimalisaties kunnen bij veel projecten binnen 1 tot 3 dagen worden uitgevoerd. Databaseanalyse, loadtesting, cachestrategie en architectuurverbeteringen kunnen afhankelijk van de complexiteit van de website enkele weken gepland werk vragen.

Hoeveel GB RAM heeft een website met veel verkeer nodig?

Dat verschilt per applicatie. Voor middelgrote dynamische websites kan 16-32 GB RAM een goed startpunt zijn. Voor drukke webshops, grote databases en projecten die intensief Redis gebruiken, is 64 GB of meer vaak een betere keuze.

Geeft NGINX of Apache betere performance?

Bij veel gelijktijdige verbindingen werkt NGINX meestal efficiënter. Apache heeft voordelen op het gebied van flexibiliteit en compatibiliteit. Met PHP-FPM, caching en goede configuratie kunnen beide opties succesvol zijn; de juiste keuze hangt af van de applicatie.

Heb ik nog dedicated server optimalisatie nodig als ik een CDN gebruik?

Ja. Een CDN verlaagt de belasting voor statische en cachebare content, maar dynamische pagina’s, betalingen, accounts, beheerpanelen en databaseprocessen blijven afhankelijk van de origin-server. Een CDN vervangt serveroptimalisatie dus niet, maar vult die aan.

Moet ik meteen naar een zwaarder pakket als mijn server traag is?

Meet eerst waar de bottleneck zit. De oorzaak kan een verkeerde query, ontbrekende cache, foutieve PHP-FPM-instelling of botverkeer zijn. Zonder die problemen op te lossen verhoogt een hardware-upgrade vooral de kosten en blijft de kernoorzaak vaak bestaan.