Opslagruimte is de makkelijkste hostingspecificatie om te begrijpen, maar zelden de eerste oorzaak van een trage website. De meeste websites gebruiken maar een deel van hun beschikbare gigabytes. Prestaties worden vaker bepaald door hoeveel rekenwerk, geheugen, schijfverkeer en gelijktijdige verzoeken het pakket aankan.
Bij Gigatech beheert CloudLinux deze middelen per account. Dat beschermt het platform en maakt pakketten beter voorspelbaar. Een limiet is geen straf: hij geeft aan hoeveel capaciteit voor uw account beschikbaar is en voorkomt dat één gebruiker alle andere klanten verdringt.
CPU: hoe snel kan de server rekenen?
De CPU voert PHP-code uit, verwerkt templates, comprimeert gegevens en helpt bij allerlei achtergrondtaken. WordPress-pagina’s met veel plugins, complexe productfilters of zware berekeningen vragen meer CPU-tijd dan een eenvoudige gecachete pagina.
Bij hosting wordt CPU soms uitgedrukt als een percentage of aantal cores. Eén volledige moderne core kan bij een korte taak zeer krachtig zijn, maar een website met veel gelijktijdige dynamische verzoeken heeft ook baat bij ruimte voor parallel werk. Caching vermindert CPU-belasting omdat een opgebouwd resultaat opnieuw kan worden gebruikt.
RAM: de werktafel van uw website
RAM is tijdelijk werkgeheugen voor PHP-processen, applicaties en caches. Te weinig geheugen kan processen laten stoppen of foutmeldingen veroorzaken. Meer RAM maakt een site echter niet automatisch sneller wanneer het echte knelpunt CPU of disk-I/O is.
Een zware pagebuilder, import, back-uptaak of webshopactie kan tijdelijk veel geheugen vragen. Daarom moet u niet alleen naar gemiddeld gebruik kijken, maar ook naar pieken. Verwijder ongebruikte plugins en plan zware achtergrondtaken buiten drukke momenten.
Disk-I/O en IOPS: snelheid van lezen en schrijven
Disk-I/O geeft aan hoeveel gegevens per seconde van opslag mogen worden gelezen of ernaartoe geschreven. IOPS telt hoeveel afzonderlijke lees- en schrijfbewerkingen per seconde plaatsvinden. Een grote kopie gebruikt veel doorvoer; duizenden kleine database- en cachebestanden kunnen juist veel IOPS vragen.
Wanneer de I/O-limiet wordt bereikt, vertraagt CloudLinux processen in plaats van andere accounts te laten lijden. U merkt dat bijvoorbeeld bij een zware back-up, malware-scan, import of slecht geoptimaliseerde plugin. Snelle SSD-opslag helpt, maar het pakket bepaalt welk deel van die capaciteit beschikbaar is.
Entry processes en NPROC: hoeveel tegelijk?
Een entry process staat grofweg voor een actief verzoek dat uw account binnenkomt en dynamisch werk uitvoert. Het is niet hetzelfde als bezoekers: één bezoeker kan meerdere verzoeken doen, terwijl gecachete bestanden soms nauwelijks dynamische capaciteit vragen. NPROC begrenst het totale aantal processen en threads binnen het account.
Als een site regelmatig de limiet voor gelijktijdigheid raakt, kan dat wijzen op legitieme drukte, trage PHP-taken, een vastgelopen proces of botverkeer. Alleen een hoger pakket kiezen zonder oorzaakonderzoek kan het probleem uitstellen in plaats van oplossen.
| Signaal | Mogelijk knelpunt | Eerste controle |
|---|---|---|
| Dynamische pagina’s zijn traag | CPU of trage databasequery | Cache, plugins en query’s analyseren |
| Fouten tijdens import of back-up | RAM, I/O of procestijd | Taakgrootte en resourcehistorie bekijken |
| Site hapert tijdens piek | Entry processes of CPU | Verkeer, bots en cache-hitratio controleren |
| Beheer blijft traag, voorkant snel | Ongecachet PHP/databasewerk | Admin-plugins, cron en database controleren |
Bandbreedte en dataverkeer zijn iets anders
Dataverkeer meet hoeveel data over een periode wordt verstuurd. Netwerkbandbreedte bepaalt hoe snel dat kan. Deze termen staan los van disk-I/O, al beïnvloeden ze samen de ervaring. Een site met grote video’s kan veel dataverkeer gebruiken zonder veel PHP te vragen; een kleine webshop kan weinig gigabytes versturen en toch intensief rekenen.
Caching verandert de rekensom
Een page cache zoals LSCache kan veel dynamische verzoeken omzetten in snelle cacheleveringen. Redis vermindert herhaald databasewerk. Daardoor kan hetzelfde pakket meer echte bezoekers verwerken. Caching moet wel correct zijn: persoonlijke pagina’s en winkelmandjes blijven dynamisch, en na updates moet verouderde inhoud worden ververst.
Wanneer upgraden?
Upgrade niet op basis van één losse piek. Bekijk gebruik over tijd en zoek naar een patroon. Als CPU, geheugen, I/O of entry processes structureel de grens raakt terwijl de applicatie gezond en goed gecachet is, past een groter pakket. Bij tijdelijke imports kan het slimmer zijn de taak op te delen of anders te plannen.
- Persoonlijke site: weinig dynamisch verkeer; caching levert veel op.
- Zakelijke WordPress-site: meer plugins, formulieren en beheer; extra geheugen en CPU-headroom zijn verstandig.
- Webshop: veel persoonlijke en databasegestuurde pagina’s; let vooral op CPU, RAM en gelijktijdigheid.
- Agency-omgeving: meerdere sites en achtergrondtaken; isolatie, I/O en monitoring worden belangrijker.
Twijfelt u welk pakket past? Bekijk onze hostingpakketten en laat ons vooral weten wat de site doet, hoeveel verkeer u verwacht en welke pieken voorkomen. Een goede keuze is gebaseerd op workload, niet alleen op schijfruimte.
