Trage WordPress-sites debuggen met Query Monitor

Procédure

Wat is Query Monitor?

WordPress, het populairste CMS, heeft vaak last van prestatieproblemen. Dit CMS biedt echter geen native tool voor het analyseren van de knelpunten die traagheid veroorzaken, wat de analyse er niet eenvoudiger op maakt.

Query Monitor is een gratis WordPress plugin die de nodige profileringstools biedt tijdens de uitvoering van elke pagina die door WordPress wordt gegenereerd om de punten te identificeren die moeten worden gecontroleerd wanneer er snelheids- en prestatieproblemen zijn.

Terwijl de gebruikelijke methode is om met vallen en opstaan elke plugin te deactiveren totdat het probleem verdwijnt, kiest Query Monitor voor een nieuwe aanpak door onmiddellijk de plugin en/of het thema te identificeren die een langzame SQL of HTTP-verzoek veroorzaken.

In deze gids leert u alles wat u moet weten om uw prestatieproblemen te identificeren met Query Monitor.

Hoe installeer ik Query Monitor?

Om Query Monitor te installeren, ga naar het dashboard van je WordPress site en ga naar Extensies en dan Toevoegen.

Zoek naar de Query Monitor plugin en installeer deze.

Eenmaal geïnstalleerd, activeer de extensie.

De Query Monitor interface

Zodra de plugin actief is, verschijnt er een nieuw menu op de menubalk van WordPress. Als je op het menu klikt, wordt het foutopsporingsvenster weergegeven:

Je moet dan naar de pagina gaan waar je prestatieproblemen ondervindt en op het menu klikken om de details te zien.

Vergeet niet om de Query Monitor plugin te deactiveren zodra je klaar bent met debuggen, want het genereren van deze debuggegevens is op zichzelf vrij omslachtig en kan leiden tot prestatieproblemen.

Overzichtsmenu

Het Query Monitor overzichtsmenu toont de URL die momenteel geopend is.

De paginageneratietijd is de tijd waarbinnen PHP het script uitvoert. De limiet die hieronder wordt vermeld, is de max_execution_time die is gedefinieerd voor PHP. Over het algemeen moet de pagina-opmaaktijd ongeveer gelijk zijn aan de wachttijd van de browser (zichtbaar via de ontwikkelconsole):

In dit voorbeeld kun je zien dat er een probleem is: de pagina-opmaaktijd is slechts 377 ms, maar de browser doet er tot 959 ms over voordat hij de pagina kan ontvangen. Dit probleem treedt op als het netwerk tussen de webbrowser en de siteserver traag is. In dit soort gevallen is het nodig om een server dichter bij de client op te zetten met behulp van Ipxchange of Cloudflare.

Het gedeelte"Piekgeheugengebruik" geeft het maximale geheugengebruik van je website aan tijdens het genereren van de pagina. De limiet voor WordPress wordt bepaald door de constante WP_MEMORY_LIMIT in wp-config.php, terwijl de limiet voor de server wordt bepaald door de memory_limit waarde die is ingesteld via de cPanel interface.

De volgende sectie,"Database queries", laat de tijd zien die wordt besteed aan het ophalen van informatie uit de database.

De sectie"HTTP API Calls" toont de HTTP-aanvragen die de site doet tijdens het genereren van pagina's om externe API's te benaderen. De responstijd van een API hangt onvermijdelijk af van de server waarop de API wordt gehost.

De laatste twee secties,"Object cache" en"Opcode cache" geven de staat van gebruik van deze twee caches aan. Er moet aan worden herinnerd dat de object cache WordPress objecten in het geheugen opslaat om het aantal MySQL verzoeken aan de database te verminderen en zo de reactietijd te optimaliseren, terwijl de Opcode cache PHP in staat stelt om het PHP bestand niet elke keer opnieuw te compileren. Zodra een PHP-bestand voor de eerste keer is uitgevoerd, slaat de Opcode cache de Opcode van het PHP-bestand op (de gecompileerde, binaire versie van het PHP-bestand) voor toekomstige uitvoering.

Als je meer wilt weten over de uitdagingen van object caching, raden we je aan onze documentatie over het opzetten van een persistente object cache met Redis te lezen.

PHP fouten menu

Dit menu toont de PHP fouten die WordPress tegenkomt (niet noodzakelijk fatale en/of blokkerende fouten). Ze zijn vaak verborgen en moeilijk te vinden zonder de PHP foutmeldingsdrempels aan te passen. Met Query Monitor kunt u ze echter snel bekijken zonder de configuratie aan te passen. De kolom"Component" toont je de oorsprong van het script dat de fout veroorzaakt, of het nu afkomstig is van de WordPress core, een thema of een bepaalde plugin. De kolom"Locatie" toont het bestand en het regelnummer.

Als je PHP fouten tegenkomt, zelfs als ze niet blokkeren, kunnen je prestaties worden beïnvloed. Als je veel fouten hebt om te loggen, moet je PHP proces het PHP logbestand openen, schrijven en sluiten bij elk nieuw bezoek. Als je deprecaties hebt, pas dan de PHP foutmeldingsdrempels aan zodat ze niet worden opgenomen in de logbestanden om onnodig schrijven naar het PHP logbestand te voorkomen als je ze op dat moment niet goed kunt oplossen.

Menu Queries

Dit menu groepeert de SQL queries die WordPress uitvoert, evenals de componenten achter de queries en hun uitvoeringstijden:

Als je bijzonder trage query's opmerkt :

• Probeer de plugin achter de query te deactiveren als deze geen vitale functionaliteit biedt aan je website (zoals een statistieken plugin, bijvoorbeeld) of verander van thema als de query afkomstig is van een slecht ontworpen thema.
• Als de query gericht is op een tabel die je kunt opschonen, aarzel dan niet om deze op te schonen zodat de grootte kleiner wordt en het zoeken naar gegevens over de tabel soepeler verloopt. Je kunt bijvoorbeeld artikelrevisies verwijderen in wp_posts om de grootte van deze tabel te verkleinen, of verlopen overgangen verwijderen in wp_options.
• Als het verzoek het resultaat is van een verzoek voor een WordPress object (zoals een Custom Post Type), dan kun je de uitvoering van dit soort verzoeken verminderen door een object cache in te stellen.
• Je kunt eenvoudig migreren naar een krachtiger aanbod zoals een VPS PRO als je een krachtigere MySQL server wilt die, als gevolg daarvan, in staat zal zijn om hetzelfde verzoek op dezelfde gegevensset met een hogere snelheid uit te voeren.

HTTP API-oproepen" menu

Met het menu "HTTP API Calls", iets verderop in de lijst, kun je de API-aanvragen bekijken die door de site zijn gedaan tijdens het laden van de pagina:

Als je een API ziet die te langzaam reageert, raden we je aan deze uit te schakelen door de bijbehorende plugin te deactiveren.

Als de duur echter ongeveer afgerond is (zoals bijvoorbeeld 30,001s), kan dit betekenen dat het API-verzoek een tijdslimiet overschrijdt, vaak als gevolg van firewallblokkering. Als de API een bron benadert die niet op de standaard poort 80 of 443 staat, vergeet dan niet te controleren of het verzoek geautoriseerd is op de firewall van de cPanel server.

Conclusie

Nu weet je hoe je de gratis Query Monitor plugin kunt gebruiken om de bron van de vertragingsproblemen op je WordPress website te identificeren. Voel je vrij om je gedachten en vragen te delen in de commentaarsectie.