Lassú adatbázis-lekérések (slow queries) megtalálása WordPress és WooCommerce oldalakban

WordPress és WooCommerce weboldalak esetében a rendszer felépítése végett rengeteg adatbázis-lekérés szolgálódik ki. Jellemzően egy nem optimalizát weboldal rengeteg bővítménnyel rendelkezik, így a lassúság oka nehezen behatárolható. Nehezebb kiszűrni a bővítmény-hibákat, a bonyolultság miatt az ok-okozati összefüggések mögött a súlyos tizedmásodperceket jelentő lekéréseket nehezebb megtalálni.

 

Az alábbi eszközökkel lehet érdemes próbálkozni, azonban mi azt ajánljuk, hogy mindenképp fejlesztő segítségét kérjék a lassú lekérések detektálásához.

 

 

Query Monitor

 

1. Beállítás

 

Telepítést követően a Bővítmények/Telepített bővítmények alatt a "Query Monitor"-t megkeresve a "Settings"-re kel kattintani. Ekkor a böngészőben alul megjelenik a bővítmény settings felülete.

 

 

Itt a "Set authentication cookie"  -ra kell kattintani. Sikeres beállítás után zöld visszajelzést kell látnunk.

 

 

2. Miket ellenőrizzek?

 

A Query Monitor bővítményből az alábbi felületeket ajánljuk mindenképp áttekintésre a sikeres vizsgálathoz.

 

2.1 Queries - Lekérések és kiszolgálásuk

 

Egy weboldal esetén leginkább adatbázis lekérések eredményei szolgáltatják az információkat. Betöltődnek a fontos tartalmak (például egy ártáblázat), kiválogatásra kerülnek a megjelenítendő cikkek, felhasználótól függően más-más tartalmak látszódhatnak.

 

Ezeket az adatbázis-folyamatokat (queries) tehát a legfontosabbak.

 

 

 

 

A fenti képen látható, hogyan tekinthető meg egy adott oldal betöltődése után a Query Monitor "Queries" részében az egyes adatbázis lekérések. A listában látható a konkrét lekérés (Query), látható az is hogy mi hívja meg a lekérést (Caller), továbbá azt is, hogy mennyi idő (Time) mire a lekérés kiszolgálódik.

 

A "Time" oszlopra kattintva sorba rendezhetőek a lekérések csökkenő-növekvő irányba is.

 

A "Time" oszlop alatt legnagyobb szám az összes lekérés-kiszolgálás idejét jelzi. Ehhez tudjuk viszonyítani lekérdezéseinket, hogy azok túl lassúak-e vagy sem.

 

Értelemszerűen minél több időbe kerül egy lekérés (vagy minél több, hosszabb ideig tartó lekérés található meg egy adott oldalon), annál lassabb lesz a weboldalunk betöltődése, kiszolgálása is.

 

Segítség: A fenti képen például az látszik, hogz a "Go Pricing" nevű bővítmény az (egész pontosan az adatbetöltése), amely lekérése a legtovább futott az adott oldalon.

 

TIPP: A Query Monitor a WordPress admin felületén is futtatható (akár egy export-import folyamatnál is), valamint az oldal frontend részén is (amit a látógató használ). Így akár egy vásárlási folyamat is visszaellenőrizhető vele, vagy akár egy keresés lefuttatása is.

 

 

2.2 - Capability checks

 

Ellenőrzéshez aktiválni kell a funkciót. Ehhez a weboldal wp-config.php -jában el kell helyezni az alábbi egysoros kódot:

 

define( 'QM_ENABLE_CAPS_PANEL', true );

 

Ezt az alábbi sor fölé kell bemásolni:

 

/* That's all, stop editing! Happy publishing. */

 

Az ellenőrzéshez egy adott oldalon a "Capability Checks"-re kell kattintani, majd a betöltődő listában láthatóak ezek a funkciók. Érdemes ezt a listát is ellenőrizni, mert alapvetően szükségtelen funkciók is engedélyezve lehetnek (például a multisite funkciók), amelyekre nincs is szükség eg egyszerű WordPress oldal esetén.

 

 

A fenti képen látható, hogy egy nem-Multisite weboldalon helyesen "false" (elérhetetlen, tiltott, stb) értéket ad vissza egy Multisite funkció (egész pontosan a Multisite hálózatban való bővítmény-menedzselés lehetősége).

 

 

2.3 - Scripts , Styles - Szkriptek és CSS-ek

 

A listák segítségével láthatóak, hogy milyen weboldalon belüli, illetve távoli (más kiszolgálóról meghívott) CSS-ek és JS-ek kerülnek meghívásra. Ezek az értékek is ellenőrizhetőek mind az admin felületen, mind a weboldal látogatók által elérhető részén is.

 

 

A "Scripts" és a "Styles" mezők abban segítenek, hogy sikerüljön egyértelműen azonosítani a Fejlécben (Header) és a Láblácben (Footer) behívott .js és .css fájlokat. Továbbá ezek szűrhetőek kiszolgáló (Host) szerint is. Így pedig a lassan betöltődő tartalmak is azonosíthatóak, áthelyezhetőek akár majd Footer-be megfelelő bővítmény segítségével, hogy a betöltődés gyorsabb lehessen.

 

 

Debug Bar

 

1. Beállítás

 

Telepítést követően szükséges a debug.log íródásának engedélyezése. Ehhez segítséget IDE KATTINTVA fog találni.

 

2. Miket ellenőrizzek?

 

Az admin felület, vagy egy adott oldal lefuttatását követően (tehát megnyitását, betöltődését követően) a jobb felső sarokban a "Debug" gombra kell kattintani.

 

 

 

Kattintást követően a "Queries" tölt be, de ha mégsem akkor erre kell kattintani. A felület segítségével sorban kilistázásra kerülnek a lefutó adatbázis-lekérések (queries). A lista nem rendezhető. Tehát manuálisan, kézzel szükséges végig nézni az egyes lekérdezéseket.

 

A Debug Bar nem emel ki lassú lekéréseket vagy nem segít táblarendezéssel. Csupán megmutat egy lekérést, illetve a lekéréshez tartozó forrásokat, amelyek ezt a lekérést elindítják.

 

TIPP: Az egyes lekérések melletti ms-os értéket (pl: "7,8 ms") szükséges viszonyítani a bővítmény fejlécében található "TOTAL QUERY TIME" értékhez. Ennek fényében kell eldönteni, hogy egy adott lekérés problémás-e vagy sem.

 

 

A fenti képen például az látszik, hogy a legtöbb időt az alábbi lekérés igényelte:

 

SELECT option_name, option_value FROM wph0_options WHERE autoload = 'yes'

 

A fenti kép szerint az "autoload" oszlop "yes" értékeinek leválogatása tart a leghosszabb ideig. Ezek a változók kontrollálják azt, hogy a "wp_load_alloptions()" funkció mely értékeket hívhatja meg automatikusan, Minden oldalbetöltés esetén!

A fenti oldal esetében tehát érdemes az "autoload" oszlop "yes" értékeit vizsgálni, nincs e túl sok szükségtelen tartalom benne.

 

 

Lehetséges megoldások

 

Adatbázis tehermentesítése:

 

Nagyon fontos a tárolómotor átállítása. Ha weboldalának tárolómotorja még MyISAM, akkor ALÁBBI LEÍRÁSUNK szerint állítsa azt át InnoDB-re.

 

A weboldalak lassú lekéréseit az alábbiak szerint lehet menedzselni, megoldani:

 

  • PHP-értékek emelése a verzió megváltoztatásával, melyről IDE KATTINTVA olvashat.

  • Azonosítható bővítményhiba esetén: bővítménycsere mindenképp ajánlott.

  • Fejlesztői segítségkérés (már a hiba megtalálásához is) az összetett megoldáshoz.

 

A fejlesztők által alkalmazott megoldások rendszerint:

 

  • adatbázis-lekérdezési hiba esetén, a problémás lekérés detektálása után annak átírása (azaz más típusú lekéréssé programozása).

  • Ezen felül az adatbázis táblákban eltárolt tartalmak Indexelése is segíthet az értékek könnyebb és gyorsabb elérésében.

  • Végül az adatbázis-lekérési eredmények cache-elésével is gyorsabb kiszolgálás érhető el.

 

Azonban ezek bőséggel túlmutatnak egy egyszerű hosting-szolgáltatás elérhetőségének biztosításában, annak menedzselésében.

 

Mindenképp ajánljuk, hogy összetett weboldal esetén (mely ráadásul bevételt is termel) a problémás lekérés megtalálásához és megoldásához fejlesztői segítséget keressen!

 

 

P3 Profiler, a felhasználóbarát kakukktojás

 

1. Beállítás

 

Telepítés után mindenképp szükséges egy megfelelő "ea-..." előjelű PHP-verziót megadni, valamint az alábbi értékeket megnövelni:

- memory_limit: 1024M vagy 1536M

- max_execution_time: 300

- zlib.output_compression: legyen KIKAPCSOLVA

 

A beállításhoz IDE KATTINTVA érhet el segítséget.

 

2. Miket ellenőrizzek?

 

A bővítmény a WordPress admin felületen belül az Eszközök/P3 Plugin Profiler -re kattintva érhető el. A kifrissülő oldalon a "Start Scan"-re kattintva indítható a feltérképezés.

 

 

Indítás előtt felugrik egy ablak, ahol lehet Automatikus vagy Manuális scan-elést is indítani. Az automatikus Scan-elés kiválasztható! A scan-elés neve is megadható még az indítás előtt.

 

 

3. Mit tegyek ha oldala elérhetetlenné válik?

 

Sajnos a magas php-limitek esetén is beakadhat a program futása, így az alábbi megoldásokkal lehet élni, ha weboldala elérhetetlenné válik, a Scan-elés nem fut végbe látszólag:

 

  • Nyissa meg az alábbi URL-t a sacn-elés megállításához
http://DOMAIN.TLD/wordpress/?P3_SHUTOFF=1

A "DOMAIN.TLD" részt természetesen írja át a saját domain nevére.

 

  • Ha ez nem hoz eredményt, akkor a weboldalának könyvtárában, a wp-content/plugins/ struktúrán belül a "p3-profiler" köznytárat nevezze át

 

Ekkor 1-2 percen belül weboldala elérhető lesz újfent. A fenti leállítások esetén is fog látni scan-elési eredményt, mely leginkább az Ön által hasznát bővítmények terhelését fogja megmutatni.

 

  • 2021, slow, queries, adatbázis-lekérések
  • 0 Users Found This Useful
Was this answer helpful?

Related Articles

Mért látom a "WordPress Account Compromise Alert" hibaüzenet a WP admin oldalamra belépve?

Mért látom a "WordPress Account Compromise Alert" hibaüzenet a WP admin oldalamra belépve? Mert...

Hogyan tehetjük biztonságosabbá honlapunkat, Wordpress és Joomla rendszerünket?

Egy 2016-ban készült statisztika szerint a világon körülbelül 37 ezer weboldalt fertőznek meg...

Wordpress áthelyezése másik domainra vagy mappába

Ha már van egy felépített Wordpress weboldala aktív domain vagy mappa alatt, és át szeretné ezt...

Wordpress admin jelszó módosítása

Ha nem tud bejelentkezni a WordPress admin felületére (a http://azondomainneve.hu/wp-admin...

Hogyan tudom költöztetni WordPress oldalam?

WordPress oldalát két módon tudja költöztetni, választhatja a manuális illetve a bővítmény általi...