Traagheid van site en resourcelimieten

What your hosting plan actually limits, what happens when you reach each limit, and how to work out whether a slow site is a resource problem or a code problem.

Wat uw hostingplan echt beperkt, wat gebeurt er wanneer u elke limiet bereikt, en hoe u kunt bepalen of een trage site een resourceprobleem of een codeprobleem is.

"Mijn site is traag" en "mijn site is zonder iets gebleven" voelen van buiten hetzelfde aan en hebben bijna niets gemeen onder de motorkap. Deze gids scheidt ze: eerst wat de limieten werkelijk zijn, vervolgens hoe u werkelijke traagheid diagnosticeert.

Eerst: traag of kapot?

Traag betekent dat pagina's laden, uiteindelijk. Kapot betekent dat ze niet laden.

Als u foutpagina's krijgt in plaats van trage pagina's, stop hier en ga naar HTTP-foutcodes. Een 500, 502 of 504 heeft een specifieke oorzaak en een specifieke oplossing, en geen van deze zijn "upgrade het plan".

Als de site onbereikbaar is in plaats van traag, ga naar Website laadt niet.

Wat uw plan werkelijk beperkt

Vier dingen, en het is de moeite waard om te weten welke welke zijn, omdat ze zich zeer verschillend gedragen wanneer u ze bereikt.

Opslag. Hoeveel schijfruimte uw bestanden en databases gebruiken. Dagelijks gemeten.

Bandbreedte. Hoeveel gegevens uw bezoekers per maand downloaden.

Aantal sites. Hoeveel afzonderlijke sites u op het plan kunt uitvoeren.

CDN-toegang. Of het CDN helemaal beschikbaar is, en hoeveel verkeer per maand vanuit de rand kan worden bediend.

Uw specifieke toewijzingen zijn afhankelijk van uw plan. De huidige cijfers voor elk plan worden naast elkaar weergegeven onder Facturering, vervolgens Plan wijzigen, wat ook de eerlijke plaats is om te vergelijken in plaats van een getal dat in een helpartikel wordt getypt en kan afwijken. Zie Uw plan upgraden.

Opslag- en CDN-gebruik op de sitenoverzichtspagina

Wat gebeurt er wanneer u elk ervan bereikt

Dit is het deel waar mensen zich zorgen over maken, en de antwoorden zijn minder dramatisch dan verwacht.

Opslag. Schijfgebruik wordt dagelijks gemeten en weergegeven op de Overview-pagina van de site. Naarmate het oploopt, krijgt u een inzichtwaarschuwing die u waarschuwt, escalerend naarmate het voller wordt. Zie Insights.

Aantal sites. Dit wordt afgedwongen op het moment van aanmaak. Probeer een site te maken die verder gaat dan de toewijzing van uw plan en u krijgt een duidelijk bericht dat het plan vol is, met de optie om bij te werken of een ander plan toe te voegen. Niets bestaands wordt beïnvloed.

CDN-geschiktheid. Het inschakelen van het CDN op een plan dat het niet omvat, geeft een duidelijk bericht "niet opgenomen in uw plan" met een upgradelink. Er is geen gedeeltelijke of verslechterde modus. Zie Het CDN inschakelen.

CDN-bandbreedte. Dit heeft echt, goed ontworpen gedrag dat het begrijpen waard is:

Bij 80% van uw maandelijkse randtoewijzing ontvangt u een e-mail.
Bij 100% wordt de rand voor de rest van de maand onderbroken. Uw site blijft online en blijft normaal bedienen, rechtstreeks van de oorsprong, het is gewoon niet langer aan de rand gecacht.
Het bedienen van randen wordt automatisch aan het begin van de volgende maand hervat.
U wordt nooit voorbij de limiet gefactureerd zonder het te weten.

Het ergste geval is dus dat uw site even snel wordt als voordat u het CDN inschakelde. Niets gaat offline.

Beheerde WordPress- en WooCommerce-bandbreedte werkt als een soft cap. U wordt gewaarschuwd wanneer u deze bereikt en opnieuw wanneer u deze overschrijdt, en elk overschot wordt behandeld als een metergestelde overschrijding in plaats van dat de site wordt uitgeschakeld.

Het overschrijden van een opslag- of bandbreedtetoewijzing schort uw site niet op. Opschorting op dit platform is een factureringstoestand, geen resource. Zie Account opgeschort en Betaling mislukt.

Wat niet per plan wordt beperkt

Twee dingen die mensen verwachten te vinden en niet zullen vinden.

Er is geen per-site CPU- of geheugenquotum op webhosting-plans. Uw plan wijst u geen aantal cores toe.

U concurreert niet met uw buren om PHP-capaciteit. Elke site wordt uitgevoerd in zijn eigen geïsoleerde pool van PHP-werkprocessen. Een drukke site naast u kan de workers die uw site nodig heeft niet uitputten. Die isolatie is echt, en daarom is "iemands anders site vertraagt de mijne" bijna nooit de verklaring op dit platform.

Wat wel van toepassing is, is een per-verzoek limiet: hoeveel geheugen één verzoek mag gebruiken en hoeveel seconden het mag draaien. Die kunt u zelf instellen. Zie PHP-extensies en -instellingen.

Waar u uw gebruik kunt zien

Opslag, op de Overview-pagina van de site.
CDN-bandbreedte, ook op de Overview-pagina zodra het CDN is ingeschakeld, en op het Kapsule CDN-tabblad van de site.
Waarschuwingen, via Insights en per e-mail. Zie Insights.
Buildminuten en bandbreedte voor Orbit-projecten, op de pagina Orbit-gebruik. Orbit heeft zijn eigen heel andere limieten, inclusief een uitgavenlimiet. Zie Orbit-planlimieten en Orbit-uitgavenlimiet.

Een trage site werkelijk sneller maken

In volgorde van rendement op inspanning. Werk de lijst af in plaats van naar de onderkant te springen.

1. Caching inschakelen

De grootste winst, elke keer. Het serveren van een opgeslagen kopie van een pagina is orders of magnitude goedkoper dan het opnieuw opbouwen ervan voor elke bezoeker.

Ga naar Websites, de site, WordPress, vervolgens Caching. Object caching is beschikbaar in alle WordPress-familie-plannen, en full-page caching in de beheerde plannen. Zie Site Caching.

Houd er rekening mee dat sommige paden opzettelijk nooit in cache worden opgeslagen: beheerpagina's, aanmelding, winkelwagen, checkout en accountpagina's. Het in cache opslaan van een checkout-pagina zou de ene klant de winkelwagen van een andere klant tonen, dus dit is niet configureerbaar en mag niet zijn.

2. Het CDN inschakelen

Caching plaatst de kopie op één plaats. Het CDN plaatst het dicht bij uw bezoekers. Grootste effect als uw publiek niet in hetzelfde land als uw server woont. Vereist een geschikt plan en uw eigen aangepaste domein. Zie Het CDN inschakelen.

3. Naar een nieuwere PHP-versie gaan

Een echt, meetbaar verschil zonder werk. Test eerst op staging. Zie PHP-versie wijzigen.

4. Uw afbeeldingen repareren

Consistent het grootste onderdeel op een trage pagina. Een foto rechtstreeks van een telefoon kan meerdere megabytes zijn en wordt weergegeven bij 400 pixels breed. Wijzig het formaat voordat u uploadt en gebruik een modern formaat.

5. Uw plugins controleren

Elke plugin die werk op elk verzoek uitvoert, kost u op elk verzoek. Deactiveer er één tegelijk en meet. Verwijder wat u niet gebruikt in plaats van het gedeactiveerd te laten. Zie WordPress-plugins.

6. Het werkelijke trage ding vinden

Stop met gissen en meet:

Het APM-tabblad op WordPress-sites toont welke verzoeken traag zijn. Zie Site Performance.
Het trage querylogboek, beschikbaar via de WordPress-gezondheidstools, toont welke databasequery's het probleem zijn.
Het PHP-trage logboek legt vast wat een verzoek deed toen het te lang duurde.
Foutenlogboeken tonen alles dat stil mislukt en opnieuw wordt geprobeerd. Zie Foutenlogboeken.

7. Dan, en alleen dan, overweeg meer resources

Als caching aan staat, het CDN aan staat, PHP is actueel, afbeeldingen zijn redelijk, en de profiler zegt dat het werk werkelijk nodig is, dan bent u uit het plan gegroeid en omhoog gaan is de juiste keuze. Zie Uw plan upgraden.

Dit stap eerst doen is hoe mensen uiteindelijk meer betalen voor een site die nog steeds traag is, omdat een niet-geoptimaliseerde site op een groter plan een niet-geoptimaliseerde site is.

Wanneer is het tijd voor een server

Gedeelde hosting is het juiste antwoord voor de overgrote meerderheid van de sites. Ga naar een cloud- of dedicated server wanneer u software nodig hebt die het platform niet biedt, root-toegang, niet-standaardservices of voorspelbare toegewezen capaciteit voor iets werkelijk zwaars. Zie Cloud Servers en Een architectuur kiezen.