Mi az a wp_options tábla?

A wp_options táblázat mindenféle adatot tartalmaz a WordPress webhelyéhez, például:

• Webhely URL-je, kezdőlap URL-je, adminisztrátori e-mail, alapértelmezett kategória, oldalankénti bejegyzések, időformátum stb
• A bővítmények, témák, widgetek beállításai
• Átmenetileg gyorsítótárban tárolt adatok

A táblázat a következő mezőket tartalmazza, amelyek közül az egyik fontosabb számunkra, ha teljesítményről van szó:

• option_id
• opció_neve
• opció_értéke
• automatikus betöltés

Az egyik fontos tudnivaló a wp_options táblával kapcsolatban az automatikus betöltés mező. Ez egy igen vagy nem értéket (jelző) tartalmaz. Ez lényegében azt szabályozza, hogy a wp_load_alloptions() függvény betöltse -e vagy sem . Az automatikusan betöltött adatok olyan adatok, amelyek a WordPress webhely minden oldalán betöltődnek . Ugyanúgy, ahogy megmutattuk, hogyan lehet letiltani bizonyos szkriptek webhelyszerte történő betöltését, ugyanez az ötlet érvényes itt is. Az autoload attribútum alapértelmezés szerint „yes”-re van állítva a fejlesztők számára, de elméletileg nem minden plugin tölti be az adatait minden oldalon.

A WordPress webhelyek problémája az, ha nagy mennyiségű automatikusan betöltött adat van a wp_options táblában. Ez általában a következők eredménye:

• Az adatokat egy beépülő modul automatikusan betölti, amikor valóban „nem”-re kell állítani. Jó példa erre egy kapcsolatfelvételi űrlap bővítmény. Minden oldalon kell adatokat betölteni, vagy csak a kapcsolati oldalon?
• A beépülő modulokat vagy a témákat eltávolítottuk a WordPress webhelyről, de a lehetőségek továbbra is elmaradnak a wp_options táblázatban. Ez azt jelentheti, hogy minden kérésnél lekérdezik a szükségtelenül automatikusan betöltött adatokat.
• A beépülő modulok és a témák fejlesztői a saját tábláik használata helyett adatokat töltenek be a wp_options táblába. Ennek mindkét oldala mellett szólnak érvek, mivel egyes fejlesztők előnyben részesítik azokat a bővítményeket, amelyek nem hoznak létre további táblákat. A wp_options táblát azonban nem úgy tervezték, hogy több ezer sort tároljon.

Mennyi a túl sok automatikusan betöltött adat? Ez természetesen változhat, de ideális esetben azt szeretné, ha ez 300 KB és 1 MB között lenne. Amint elkezdi megközelíteni a 3-5 MB-os vagy nagyobb tartományt, valószínűleg vannak olyan dolgok, amelyek optimalizálhatók vagy eltávolíthatók az automatikus betöltésből. És minden 10 MB felett azonnal foglalkozni kell. Ez nem mindig jelenti azt, hogy problémát okoz, de jó kiindulópont.

Automatikusan betöltött adatok hibaelhárítása a wp_options táblában

Ha lassúságot tapasztal WordPress-webhelyén, annak egy régi WordPress-bővítményből visszamaradt lekérdezés vagy automatikusan betöltött adatok oka lehet. Az alábbiakban bemutatjuk, hogyan ellenőrizheti az automatikusan betöltött méretét az adatbázisában, valamint hogyan lehet belemerülni egy élő webhely adataiba, és megosztani, mit tettünk a tisztítás érdekében.

Ellenőrizze az automatikusan betöltött adatok méretét

Az első dolog, hogy ellenőrizze az aktuális automatikusan betöltött méretet a WordPress webhelyén. Ehhez  jelentkezzen be a phpMyAdminba . Kattintson az adatbázisra a bal oldalon, majd az SQL fülre. Ezután írja be a következő parancsot, és nyomja meg a „Go” gombot.

SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload='yes';

Előfordulhat, hogy módosítania kell a fenti lekérdezést, ha WordPress-webhelye a wp_ előtagtól eltérő előtagot használ.

Az autoload_size értéke bájtokban tér vissza. 1024 bájt van egy KB-ban és 1024 KB egy MB-ban. Így esetünkben 249 025 bájt 0,25 MB-nak felel meg. Tehát ehhez az oldalhoz ez jó méret! Ha 1 MB alatti értéket küld vissza, nem kell aggódnia. Ha azonban az eredmény sokkal nagyobb volt, folytassa ezzel az oktatóanyaggal.

Az alábbiakban egy webhelyet teszteltünk, amelyen 137 724 715 bájt, vagy inkább 137 MB érkezett vissza. Ez egy jó példa arra az oldalra, ahol valami határozottan nincs rendben, vagy inkább van mit optimalizálni.

Használhat hosszabb lekérdezést is, például az alábbiakat. Ez megmutatja az automatikusan betöltött adatok méretét, hány bejegyzés található a táblázatban, és az első 10 bejegyzést méret szerint.

SELECT 'autoloaded data in KiB' as name, ROUND(SUM(LENGTH(option_value))/ 1024) as value FROM wp_options WHERE autoload='yes'
UNION
SELECT 'autoloaded data count', count(*) FROM wp_options WHERE autoload='yes'
UNION
(SELECT option_name, length(option_value) FROM wp_options WHERE autoload='yes' ORDER BY length(option_value) DESC LIMIT 10)

Ha hozzáfér a New Relichez , akkor a wp_options táblához kapcsolódó lekérdezések hibaelhárítására is használhatja. Az adatbázisok lap megmutatja a legtöbb időt igénylő lekérdezés tábláját és típusát. Ha kiválaszt egy bejegyzést a listában, további részleteket láthat, beleértve néhány mintalekérdezést. Az alábbi példában láthatja, hogy az adatok a wp_options tábla automatikusan betöltött adataira mutatnak. Az biztos, hogy a kérdéses oldal gyors elemzése közel 250 MB automatikusan betöltött adatot igazolt.

Legjobb automatikusan betöltött adatok rendezése

A következő lépés az lenne, hogy gyorsan rendezze a legfontosabb elemeket automatikusan feltöltött adatokkal. Íme egy gyors SQL-parancs, amellyel felsorolhatja a legjobb 10-et:

SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 10;

Ismételten előfordulhat, hogy módosítania kell a fenti lekérdezést, ha WordPress-webhelye a wp_ előtagtól eltérő előtagot használ.

Az egyes automatikusan betöltött adatokba való beleásás a wp_options fájlban

A következő lépés az volt, hogy beleássunk néhány legfontosabb automatikusan betöltött adatot.

301_redirects

Amint fentebb láthatjuk, a legfelső automatikusan betöltött opció a 301_redirects. Ez valószínűleg közvetlenül kapcsolódik a webhelyen található átirányítási bővítményhez vagy a WordPress SEO beépülő moduljához , amely szintén rendelkezik átirányítási funkcióval. Ebben az esetben a legjobb javaslat az átirányítások tényleges megvalósítása szerverszinten.

Miért? Mert az ingyenes WordPress beépülő modulok használata az átirányítások megvalósításához néha teljesítményproblémákat okozhat, mivel legtöbbjük a  wp_redirect függvényt használja , amely további kódvégrehajtást és erőforrásokat igényel. És természetesen automatikusan betölti az adatokat a wp_options táblába.

Ha Ön Kinsta kliens, könnyen hozzáadhat átirányításokat szerverszinten az átirányítási szabályok eszközével . Ez nem csak a teljesítmény szempontjából jobb, de így akár eggyel kevesebb beépülő modul miatt is kell aggódnia!

wpurp_custom_template_

A következő legnépszerűbb automatikusan betöltött adatopció a wpurp_custom_template_# volt. Láthatjuk, hogy ehhez elég sok különböző sor létezik. Általában a témák vagy a beépülő modulok mappájában találhatja meg ezt az opciót, és csatlakoztathatja a pontokat. Ebben az esetben egy grep parancsot adtunk a szerverről, hogy megnézzük, megtaláljuk-e. Helyszínen is ellenőrizheti SFTP-n keresztül.

grep -Ri "wpurp_custom_template_"

A fenti parancs azonban nem adott vissza semmit, ezért átmentünk a Google-hoz és keresést végeztünk. Hamar rájöttünk, hogy ez egy olyan WordPress beépülő modulhoz kapcsolódik, amely már nincs telepítve az oldalra, amely WP Ultimate Recipe néven ismert. Ez egy klasszikus példa a szükségtelenül automatikusan betöltött adatok hátrahagyására. Van egy hosszú oktatóanyagunk a WordPress bővítmények eltávolításáról (a megfelelő módon). És a megfelelő alatt azt értjük, hogy ténylegesen megtisztítjuk azt, ami hátra van.

um_cache_userdata_

A következő legnépszerűbb automatikusan betöltött adatopció az um_cache_userdata_# volt. Láthatjuk, hogy ehhez elég sok különböző sor létezik. Mivel ez az alsó rész volt, gyorsan módosítottuk a MySQL parancsot, hogy megjelenítse a 40 legjobban feltöltött adatot:

SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 40;

Vagy összegezze az összes értéket ezzel az előtaggal:

SELECT 'sum size in KiB', ROUND(SUM(length(option_value))/1024,0) FROM wp_options WHERE autoload='yes' AND option_name like "um_cache_userdata_%"

Láthattuk, hogy sokkal több bejegyzés volt az um_cache_userdata_# számára a wp_options táblában. Ismét lefuttattunk egy grep parancsot, hogy ellenőrizzük a bővítményeket és a témák mappáit.

grep -Ri "um_cache_userdata_"

Ezután gyorsan tudtuk azonosítani, hogy ez az Ultimate Member beépülő modulhoz kapcsolódik. Egy másik gyors Google-keresés néhány jó megoldást adott erre a problémára (lásd a támogatási cikket ). Soha ne becsülje alá a Google Keresés erejét! Kiderült, hogy a beépülő modulban több különböző lehetőség is elérhető a probléma megoldására.

• Ultimate Member > Irányítópult > Felhasználói gyorsítótár > Gyorsítótár törlése.
• Ultimate Member -> Beállítások -> Speciális -> Állítsa le a felhasználói profiladatok gyorsítótárazását (kapcsolja BE állásba), majd Mentse el a Változásokat.

Egy másik lehetőség annak megtekintéséhez, hogy mi az automatikusan betöltődő lehetőség, ha megnyomja a szerkesztés gombot, amely megjelenítheti a bővítmény/téma könyvtárát vagy a fejlesztő webhelyét.

Cron Jobs

Egy másik gyakori lehetőség, amelyet nagy mennyiségű automatikusan betöltött adat esetén látunk, a cron . Ehhez bármi cronnal kapcsolatos lehet. Tehát mit tehet, hogy megnyomja a „szerkesztés” gombot, hogy megnézze, mi okozza. Az alábbiakban látható egy példa, amelyből nyilvánvaló volt, hogy a „do_pings” okozta a problémát. Egy gyors Google-keresés ismét feltárt egy gyors megoldást a do_pings tisztítására .

A wp_options táblázat tisztítása

Ha sok mindent lát, amit fent említettünk, akkor valószínűleg itt az ideje, hogy megtisztítsa az összes automatikusan betöltött adatot a wp_options táblában. Javasoljuk továbbá, hogy a wp_options tábla sorainak számát minimálisra csökkentse. Kérjük, mindig készítsen biztonsági másolatot , mielőtt törli az adatokat az adatbázisban. Ha nem érzi magát kényelmesen ezt megtenni, mindig azt javasoljuk, hogy  béreljen fel egy WordPress fejlesztőt . Ez is egy jó forgatókönyv, ahol jól jöhet egy színpadi környezet .

Ahogy korábban tettük, be kell  jelentkeznie a phpMyAdminba . Kattintson az adatbázisra a bal oldalon, majd az SQL fülre. Ezután írja be a következő parancsot, és nyomja meg a „Go” gombot.

SELECT * FROM `wp_options` WHERE `autoload` = 'yes'

Előfordulhat, hogy módosítania kell a fenti lekérdezést, ha WordPress-webhelye a wp_ előtagtól eltérő előtagot használ. Ez megjeleníti az összes adatot a wp_options táblában, amely automatikus betöltésre van beállítva.

A sorok között lefelé görgetve mindenféle bővítményt látunk, amelyeket már nem telepít vagy használ a webhely. Ez csak egy példa, amelyet használni fogunk, de ebben az esetben egy csomó Jetpack sort vettünk észre. A Jetpack -et már nem használták a kérdéses oldalon.

Mindig érdemes átnézni a bővítmény fejlesztőjének dokumentációját, mert néha van lehetőségük megtisztítani a hátrahagyott asztalokat. Ebben az esetben néha biztonságosabb és egyszerűbb egyszerűen újratelepíteni a beépülő modult, ellenőrizni az automatikus tisztítási opciót, majd megfelelően eltávolítani a beépülő modult. Megmutatjuk azonban, hogyan tisztítsa meg kézzel az asztalokat.

Tehát ebben az esetben a következő lekérdezést futtatjuk, hogy megkeressük az automatikusan betöltött adatokat a Jetpack beépülő modul wp_options táblájában. A lekérdezés saját módosításához egyszerűen cserélje ki a %jetpack%.

SELECT * 
FROM `wp_options` 
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%jetpack%'

Ezután kijelölheti az összes sort, és kattintson a „Törlés” gombra.

Vagy futtathatja a következő parancsot:

DELETE
FROM `wp_options` 
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%jetpack%'

Ezután átöblítheti és megismételheti a további automatikusan betöltött adatokat, amelyek a beépülő modulokból és témákból maradtak vissza a wp_options táblázatban.

Tisztítsa meg a tranzienseket

Hacsak nem objektum-gyorsítótárat használ, a WordPress az átmeneti rekordokat a wp_options táblában tárolja. Ezeknek általában lejárati idejük van megadva, és idővel el kell tűnniük. Ez azonban nem mindig van így. Láttunk néhány adatbázist, ahol több ezer régi tranziens rekord van. Azt is fontos megjegyezni, hogy a tranziensek alapértelmezés szerint nem töltődnek be automatikusan. Az alábbihoz hasonló lekérdezéssel ellenőrizheti, hogy vannak-e automatikusan betöltött tranziens adatok.

SELECT * 
FROM `wp_options` 
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%transient%'

Azonban jobb és biztonságosabb megoldás egy ingyenes beépülő modul, például a Transient Cleaner használata, amely csak a lejárt tranzienseket tudja kitisztítani a wp_options táblából.

Tisztítsa meg a WordPress munkameneteket

Egy másik gyakori probléma, amit tapasztaltunk, hogy a cron jobok néha nem szinkronizálódnak, vagy nem indulnak megfelelően, ezért a munkamenetek nem kerülnek tisztításra. Rengeteg _wp_session_sor kerülhet az adatbázisába. Az alábbi példában a kérdéses webhely több mint 3 millió sorral zárult a wp_optionstáblázatában. A táblázat mérete pedig több mint 600 MB-ra nőtt.

Az alábbihoz hasonló lekérdezéssel ellenőrizheti, hogy találkozik-e ezzel a problémával:

SELECT * 
FROM `wp_options` 
WHERE `option_name` LIKE '_wp_session_%'

A legtöbb esetben biztonságosan törölheti ezeket (a cron joboknak megfelelően) a következő paranccsal:

DELETE FROM `wp_options` 
WHERE `option_name` LIKE '_wp_session_%'

Az összes maradék eltávolítása után _wp_session_ rowsa táblázatban kevesebb mint 1000 sor volt, és mérete 11 MB-ra csökkent.

Kijavította a MySQL -ben elért csúcsokat is .

Adjon hozzá egy indexet az automatikus betöltéshez

És ha a wp_options tábla megtisztítása nem lenne elég, megpróbálhat hozzáadni egy „indexet” az automatikus betöltés mezőhöz. Ez alapvetően segítheti a hatékonyabb keresést. A 10 up-nál dolgozó nagyszerű csapat végrehajtott néhány tesztforgatókönyvet egy wp_options táblán, tipikus számú automatikusan betöltött rekorddal, hogy bemutassa, hogyan javíthatja a teljesítményt egy automatikus betöltési index hozzáadása a wp_options lekérdezésekhez.

Azt is javasoljuk, hogy nézze meg a WP Bullet két további forrását:

• MySQL index hozzáadása a wp_options táblához
• A wp_options tábla tisztítása a WP-CLI segítségével

Még több optimalizálási tippért tekintse meg részletes útmutatónkat:  Hogyan lehet felgyorsítani a WordPress webhelyét (végső útmutató)