Betygsätt denna artikel :
5/5 | 1 Yttrande
Den här artikeln var användbar för dig ?
Ja
Nej
Vous avez noté 0 étoile(s)
Sommaire
Procédure
WordPress, det mest populära CMS-systemet, är ofta föremål för prestandaproblem. Detta CMS har dock inget inbyggt verktyg för att analysera de flaskhalsar som orsakar långsamheten, vilket inte gör analysen enklare.
Query Monitor är ett gratis WordPress-plugin som tillhandahåller de nödvändiga profileringsverktygen under exekveringen av varje sida som genereras av WordPress för att identifiera de punkter som ska kontrolleras när det finns hastighets- och prestandaproblem.
Medan den vanliga metoden är att prova sig fram genom att inaktivera varje plugin tills problemet försvinner, tar Query Monitor ett nytt grepp genom att omedelbart identifiera det plugin och/eller tema som orsakar en långsam SQL- eller HTTP-begäran.
I den här guiden får du lära dig allt du behöver veta för att identifiera dina prestandaproblem med Query Monitor.
För att installera Query Monitor, gå till instrumentpanelen på din WordPress-webbplats och gå till Extensions och sedan Add.

Sök efter Query Monitor-pluginet och installera det.

När du har installerat det aktiverar du tillägget.

Så snart tillägget är aktivt visas en ny meny i WordPress-menyraden. Om du klickar på menyn visas felsökningsfönstret:

Du måste då gå till den sida där du upplever prestandaproblem och klicka på menyn för att se detaljerna.
Glöm inte att avaktivera plugin-programmet Query Monitor så snart du har avslutat felsökningen, eftersom genereringen av dessa felsökningsdata i sig är ganska besvärlig och kan leda till prestandaproblem.
Query Monitors översiktsmeny visar den URL som för närvarande är öppen.
Sidans genereringstid är den tid under vilken PHP exekverar skriptet. Gränsen som nämns nedan är max_execution_time som definieras för PHP. I allmänhet bör sidgenereringstiden vara ungefär densamma som webbläsarens väntetid (synlig från utvecklarkonsolen):

I det här exemplet kan du se att det finns ett problem: sidans genereringstid är bara 377 ms, men webbläsaren tar upp till 959 ms innan den kan ta emot sidan. Detta problem uppstår när nätverket mellan webbläsaren och webbplatsservern är långsamt. I den här typen av fall är det nödvändigt att sätta upp en server närmare klienten med hjälp av Ipxchange eller Cloudflare.
Avsnittet "Maximalminnesanvändning" anger den maximala minnesförbrukningen på din webbplats vid generering av sidan. WordPress-gränsen definieras av konstanten WP_MEMORY_LIMIT i wp-config.php, medan servergränsen definieras av memory_limit-värdet som ställs in från cPanel-gränssnittet.
Nästa avsnitt,"Databasförfrågningar", visar den tid som går åt till att hämta information från databasen.
Avsnittet "HTTP API Calls" visar de HTTP-förfrågningar som görs av webbplatsen under sidgenerering för att komma åt externa API:er. Svarstiden för ett API kommer oundvikligen att bero på den server där API:et är hostat.
De två sista avsnitten,"Object cache" och"Opcode cache", visar hur dessa två cacheminnen används. Man bör komma ihåg att objektcachen lagrar WordPress-objekt i minnet för att minska antalet MySQL-förfrågningar som görs till databasen och därmed optimera svarstiden, medan Opcode-cachen gör att PHP inte behöver kompilera om PHP-filen varje gång. När en PHP-fil har exekverats för första gången lagrar Opcode-cachen PHP-filens Opcode (den kompilerade, binära versionen av PHP-filen) för framtida exekvering.

Om du vill veta mer om utmaningarna med objektcachelagring rekommenderar vi att du läser vår dokumentation om hur du ställer in en beständig objektcache med Redis.

Den här menyn visar de PHP-fel som WordPress stöter på (inte nödvändigtvis fatala och/eller blockerande fel). De är ofta dolda och svåra att hitta utan att ändra tröskelvärdena för rapportering av PHP-fel. Med Query Monitor kan du dock snabbt se dem utan att ändra någon konfiguration. Kolumnen"Komponent" visar ursprunget till det skript som orsakar felet, oavsett om det kommer från WordPress-kärnan, ett tema eller ett visst plugin. Kolumnen"Location" visar filen och dess radnummer.
Om du stöter på PHP-fel, även om de inte är blockerande, kan din prestanda påverkas. Om du har många fel att logga kommer din PHP-process att behöva öppna, skriva och stänga PHP-loggfilen vid varje nytt besök. Om du har avskrivningar, justera tröskelvärdena för PHP-felrapportering så att de inte ingår i loggfilerna för att undvika onödiga skrivningar till PHP-loggfilen om du inte kan lösa dem korrekt för tillfället.
I den här menyn grupperas de SQL-frågor som utförs av WordPress, samt komponenterna bakom frågorna och deras exekveringstider:

Om du märker särskilt långsamma frågor :
I menyn "HTTP API-anrop", lite längre ner i listan, kan du visa de API-förfrågningar som görs av webbplatsen under sidladdningen:

Om du märker att ett API svarar för långsamt rekommenderar vi att du inaktiverar det genom att avaktivera det tillhörande insticksprogrammet.
Om varaktigheten däremot är ungefärligt avrundad (t.ex. 30,001 s) kan det betyda att API-begäran överskrider en tidsgräns, ofta på grund av brandväggsblockering. Om API:et har åtkomst till en resurs som inte finns på standardport 80 eller 443, glöm inte att kontrollera att begäran är auktoriserad på cPanel-serverns brandvägg.
Nu vet du hur du använder det kostnadsfria pluginet Query Monitor för att identifiera källan till problemen med inbromsningar på din WordPress-webbplats. Dela gärna med dig av dina tankar och frågor i kommentarsfältet.
Betygsätt denna artikel :
5/5 | 1 Yttrande
Den här artikeln var användbar för dig ?
Ja
Nej
1mn läsning
Hur konfigurerar jag Cloudflare på en webbplats som är hostad på cPanel?
3mn läsning
Hur använder du Memcached på din cPanel-webbplats?
4mn läsning
Använda Redis som en ihållande objektcache för WordPress på cPanel
4mn läsning
Snabba upp din webbplats med Fastest Cache - Cache Varnish