Artiklite kataloog
Ma haldan mitut WordPressi veebisaiti ja ükskord kaotasin 502 vea tõttu ühe päevaga üle 800 külastuse. Pärast kolmepäevast uurimist avastasin, et süüdlane oli taustasüsteemis silmapaistmatus kohas.
Igaüks, kes haldab WordPressi veebisaiti, teab, et kõige frustreerivam pole mitte liikluse puudumine, vaid see, kui veebisait muutub ootamatult ligipääsmatuks ja ekraanile ilmuvad moonutatud vead nagu 500, 502, 503 ja 504.
Arvasid, et server on kokku jooksnud ja tormasid majutusteenuse pakkujaga vaidlema, kuid pärast nende kontrollimist said teada, et server on täiesti korras.
Võid arvata, et tegemist on pluginate konfliktiga, seega keelad ja lahendad veaotsinguid ükshaaval, kulutades sellele suurema osa päevast, aga viga kordub ikka ja jälle.
Tegelikult ei pea see nii keeruline olema. Pärast lugematutesse lõksudesse langemist avastasin, et 80% WP veebilehe 5xx vigadest ei pääse nende kolme süüdlase eest. Igaüks neist on hästi peidetud, kuid see võib teie veebisaidi kergesti rikkuda.
Nüüd toon oma praktilise kogemuse abil need lõksud selgelt esile, et isegi algajad saaksid edaspidi kurssi viia ja vigu otsida ning te ei pea enam kunagi vigadega silmitsi seisma.
Süüdlane nr 1: WP-CRON-i ei keelatud, vaid sisuliselt paigaldati veebisaidile "varjatud energiatarve".
Paljud inimesed ei tea, et WordPressil on sisseehitatud ajastatud ülesannete funktsioon nimega WP-CRON, mis on vaikimisi lubatud.
Selle funktsioonid kõlavad väga praktilistena, näiteks artiklite avaldamise ajastamine, automaatne varundamine, pistikprogrammide värskenduste kontrollimine ja isegi liikmetele meeldetuletuste saatmine.
Aga kas teadsite, et see pealtnäha kasulik funktsioon on tegelikult peamine süüdlane serverite krahhide ja 5xx vigade põhjustajate seas?
WP-CRON erineb serveri enda Cronist. See ei tööta ennetavalt, vaid käivitub kasutajate külastuste põhjal. Iga kord, kui kasutaja teie veebisaiti külastab, käivitab see salaja faili /wp-cron.php, et kontrollida, kas on mingeid ajastatud ülesandeid, mida täita.
See tähendab, et iga teie veebisaidi külastaja lisab "lisakoormuse" ja mida rohkem teil külastajaid on, seda raskemaks koormus muutub.
Mul oli kunagi veebisait, mida külastas üle tuhande inimese päevas. Kui WP-CRON polnud keelatud, tõusis serveri protsessori kasutus sageli üle 80% ja iga päev esines vähemalt kaks 503 viga, mille puhul külastajad suunati kohe pärast klõpsamist vealehele.
Veelgi hullem on see, et isegi kui te ei määra ühtegi ajastatud ülesannet, käivitub WP-CRON automaatselt, taotledes korduvalt serveriressursse. Aja jooksul ei suuda server koormusega toime tulla ja annab veateate.
GitHubi dokumentatsioon ütleb selgelt: "Ootamatu HTTP vastuse kood: 500 või kõrgem, see tähendab, et teie serveris on tekkinud viga, mis takistab cron spawneri käivitamist." See tähendab, et kui WP-CRON ei tööta korralikult, põhjustab see serveri vea 500 või kõrgema väärtusega.
Õige lähenemisviis on keelata vaikimisi WP-CRON ja kasutada serveri enda ajastatud ülesandeid. See tagab ajastatud ülesannete normaalse täitmise ja vähendab serveri koormust.
Kui teie server toetab käsku curl, saate otse lisada ajastatud ülesande, näiteks selle (muutke vastavalt oma veebisaidi domeenile):
*/15 * * * * curl https://www. 你的域名/wp-cron.php?doing_wp_cron > /dev/null 2>&1See käsk käivitab WP-CRON-i ülesande iga 15 minuti järel, mis sobib enamiku väikeste ja keskmise suurusega veebisaitide jaoks; kui teie veebisaidil on sagedased ajastatud ülesanded, saate kasutada ka seda:
*/5 * * * * curl https://www. 你的域名/wp-cron.php?doing_wp_cron > /dev/null 2>&1Pärast WP-CRON-i keelamist ja serveris ajastatud ülesannete seadistamist langes serveri protsessori kasutus alla 30% ja terve kuu jooksul ei esinenud ühtegi 503 viga. Külastajate püsivusmäär suurenes samuti 18%.
Süüdlane number kaks: korduvad CRON-i ajastatud ülesanded ja pluginate desinstallimise järel järelejäänud failid sisuliselt "jätavad veebisaidile rämpsu".
WP-CRON-i probleemi lahendamine ei tähenda, et saate rahulikult puhata; on olemas varjatud lõks, mida paljud veebisaitide omanikud eiravad.
See tähendab, et CRON-i ajastatud ülesanded töötavad korduvalt või et pärast plugina desinstallimist töötavad allesjäänud ajastatud ülesanded endiselt salaja.
Kas olete kunagi kogenud järgmist: desinstallisite varundusplugina, aga avastasite, et server varundab ikkagi automaatselt iga päev või kuvab isegi varundamise tõrketeate, mis lõpuks viib 500-veani?
Selle põhjuseks on pluginast jäänud ajastatud ülesanded.
Näiteks kui plugin genereerib igapäevase ajastatud ülesande, jätkab WordPress selle ülesande täitmist ka pärast plugini desinstallimist. Sellised ajastatud ülesanded on mõttetud. Need mõttetud jääkülesanded tarbivad pidevalt serveriressursse ja viivad lõpuks vigadeni.
Veelgi hullem on see, et mõned pluginad genereerivad automaatselt mitu korduvat ajastatud ülesannet. Näiteks võidakse ülesanne "igapäevane värskenduste kontroll" luua viis korda ja igaüks neist käivitatakse ajakava alusel, mis tähendab, et server peaks samaaegselt töötlema viit identset ülesannet.
Olin varem installinud SEO plugini, aga pärast selle desinstallimist ei pööranud ma sellele tähelepanu. Pool kuud hiljem ilmus mu veebisaidile sageli 504 ajalõpu viga. Pärast serverilogide kontrollimist avastasin, et plugin oli jätnud maha kolm igapäevast ajastatud ülesannet, mille igaühe täitmisaeg oli 12 sekundit. Kolme ülesande samaaegne täitmine põhjustas otseselt serveri vastuse ajalõpu.
Veelgi hirmutavam on see, et need korduvad ajastatud ülesanded on WordPressi taustsüsteemis nähtamatud ja teil pole aimugi, et need salaja töötavad.
Siiski on lahendus: WP-Crontrol plugin saab sellega suurepäraselt hakkama. See on WordPressi soovitatud ametlik Croni ülesannete haldamise tööriist, mis võimaldab teil kõiki ajastatud ülesandeid otse taustaprogrammis vaadata, muuta ja kustutada.
WordPressi plugina kirjelduse kohaselt saab WP-Crontrol "vaadata kõiki ajastatud cron-sündmusi, neid muuta, kustutada, peatada, jätkata ja koheselt cron-sündmusi käivitada". Teisisõnu, see saab vaadata kõiki ajastatud ülesandeid ja kustutada duplikaatseid või kehtetuid ülesandeid. Seda on väga lihtne kasutada ja see ei nõua ühegi koodirea kirjutamist.
Pärast selle pistikprogrammi kasutamist tõrkeotsinguks kustutasin 8 duplikaatülesannet ja 5 pistikprogrammi jäänusteülesannet ning veebisaidi reageerimiskiirus paranes otse 40%. Viga 504 ei tekkinud enam kunagi.
Ettevaatust: ülesannete kustutamisel kontrollige hoolikalt ja vältige kogemata WordPressi põhiliste ajastatud ülesannete, näiteks "wp_version_check" (versioonikontroll), kustutamist. Juhuslik kustutamine võib takistada veebisaidi korralikku värskendamist.
Kuigi WP-Crontroli plugin saab käsitsi kustutada duplikaatseid või kehtetuid ülesandeid, nõuab see käsitsi sekkumist, mis pole ideaalne...
Kuid me saame seda protsessi WordPressi koodi abil automatiseerida. Üksikasjade saamiseks vaadake allolevat õpetust. ▼
Süüdlane nr 3: WordPressi üleliigsed andmebaasid
WordPressis on üks 500 vea põhjuseid andmebaasi koondamine, eriti teatud pluginate loodud suured andmetabelid.
WP optimeerimise pluginat kasutades avastasin, et mõned andmetabelid olid ebanormaalselt suured, eriti Wordfence'i konfiguratsioonitabel (wfconfig) .
Probleemi analüüs
- wfconfigil on tõsine andmetabelite koondamine.Seda puhastati küll korra varem, aga see ilmus väga kiiresti uuesti nähtavale.
- Vaikimisi salvestusmootori probleemidWordfence'i konfiguratsioonitabel kasutab InnoDB vaikemootorit, mis kogub aja jooksul sadu MB koondatud andmeid.
- Mõju jõudluseleAndmetabelid võivad kergesti ulatuda sadade MB-deni, põhjustades veebisaidi laadimiskiiruse langust ja isegi 500 vea tekkimist.
Lahendus
Seda seetõttu, et Wordfence'i konfigureeritud andmetabelid kasutavad vaikimisi Inno mootorit. Aja jooksul koguneb see kiiresti sadadesse megabaitidesse ulatuvateks koondatud andmeteks, mis mõjutab veebisaidi laadimiskiirust.
Juhiste saamiseks MariaDB vaikesalvestusmootori MyISAM-iks muutmise kohta HestiaCP abil vaadake järgmist õpetust:
Neljas süüdlane: Pluginate/teemade uuendamise järgsed vead on nagu veebisaidil "ebatavalise operatsiooni" tegemine.
Paljudel veebisaitide omanikel on komme kohe klõpsata nupul „värskenda”, kui nad näevad pluginate või teemade värskendamise juhiseid, uskudes, et värskendused parandavad haavatavusi ja parandavad jõudlust.
Aga tõde on hoopis vastupidine; paljud 5xx vead on põhjustatud pluginate või teemade värskendamisest.
Olen selle probleemiga varemgi kokku puutunud. Eelmisel kuul uuendasin oma veebisaiti populaarse lehekoostaja pistikprogrammiga. Pärast nupule „Uuenda” klõpsamist muutus leht tühjaks ja pärast värskendamist ilmus 500 Internal Server Error, mis muutis taustaprogrammile juurdepääsu võimatuks.
Hiljem selgus, et plugina uus versioon ei ühildu minu veebisaidi PHP versiooniga. Pärast plugina värskendamist ei saanud kood korralikult töötada, mis põhjustas serverile otsekohese veateate.
Pluginate või teemade uuendamise järgsed vead on WordPress 500 vigade levinud põhjus, eriti kui plugina uuel versioonil on koodi haavatavusi või see on vastuolus veebisaidi teiste pluginate või teemadega.
Teine stsenaarium on see, et pärast teema uuendamist kirjutatakse eelmine kohandatud kood üle, mis põhjustab veebisaidi paigutuse korratust ja funktsioonide tõrkeid, mis omakorda viib 502 ja 503 vigadeni.
Üks mu e-kaubandusega tegelev sõber koges pärast WooCommerce'i plugina uuendamist oma veebisaidil 502 viga, mis muutis tellimuste esitamise võimatuks. Ta kaotas vaid 3 tunniga müügist üle 2000 jüaani ja probleemi lahendamiseks kulus tal terve pärastlõuna.
Tegelikult on selle olukorra kõige otsesem ja tõhusam lahendus naasta varasema, korrektselt toiminud versiooni juurde.
Paljud inimesed ei tea, kuidas tagasi pöörata, aga te ei pea faile käsitsi alla laadima ega üles laadima; WP Rollback plugin teeb selle lihtsaks.
WordPressi kirjelduse kohaselt saab WP Rollback plugin "kiiresti ja hõlpsalt taastada mis tahes teema või plugina wordpress.org-ist mis tahes eelmisele (või uuemale) versioonile ilma käsitsi vaevata". Teisisõnu, see saab pluginad või teemad taastada mis tahes eelmisele versioonile ühe klõpsuga, ilma keerukate toiminguteta, muutes selle kasutamise algajatele lihtsaks.
Pärast seda, kui minu viimane pluginate uuendamine ebaõnnestus, kasutasin WP Rollbacki, et ühe klõpsuga eelmisele versioonile tagasi pöörduda. Veebisait oli 30 sekundiga tagasi normaalses seisukorras ja andmeid ei kadunud.
Siin on soovitus: enne pluginate või teemade uuendamist varundage alati oma veebisait. Enne ametlikul veebisaidil uuendamist on kõige parem seda kõigepealt testkeskkonnas testida, et veenduda probleemide puudumises ja vältida vigu.
Kokkuvõte: omandage need 3 punkti, et WP veebisaidi 5xx vigadega täielikult hüvasti jätta.
WordPressi veebisaidi käitamisel on 500, 502, 503 ja 504 vead nagu "takistused", mis näivad olevat tülikad, kuid algpõhjus on tegelikult üsna selge – asi pole serveri vigases ega veebisaidi programmis suuremas probleemis, vaid pigem selles, et oleme kahe silma vahele jätnud kolm detaili: WP-CRON, järelejäänud ajastatud ülesanded ja pluginate/teemade uuendused.
WordPressi veebisaidi omanikuna, kes oli alguses vigadest ülekoormatud ja nüüd suudab ta kiiresti kõik 5xx vead lahendada, on minu suurim järeldus see, et veebisaidi stabiilne toimimine ei sõltu "talli ukse lukustamisest pärast hobuse põgenemist", vaid pigem sellest, et "ennetamine on parem kui ravi".
Paljud veebisaitide omanikud arvavad, et need väikesed detailid on ebaolulised ja kahetsevad nende eelnevat kontrollimata jätmist alles siis, kui veebisait ei tööta korralikult, kaotab liiklust ja kannatab tulude languse all.
Oluline on mõista, et veebisaidi puhul on "stabiilsus" peamine konkurentsieelis. Üksainus 5xx viga võib põhjustada 10% külastajate kaotuse ja mitu viga võivad isegi otsingumootori paremusjärjestuse languse põhjustada, muutes kõik teie varasemad SEO-pingutused raisku.
Nagu öeldakse: „Tuhande miili pikkusest tammist võib sipelgaauk läbi murda.“ WP veebisaidi 5xx vead ei ilmu kunagi äkki, vaid on väikeste probleemide kuhjumise tulemus – keelamata WP-CRON, järelejäänud ajastatud ülesanded ja kiirustades tehtud uuendustoimingud. Need pealtnäha tähtsusetud „sipelgaaugud“ hävitavad lõpuks kogu veebisaidi „tammi“.
Tõeliselt tõhus tegevus tähendab probleemide lahendamist juba eos.
- Keela vaikimisi WP-CRON ja asenda see serveripõhise ajastatud ülesandega;
- Kasutage regulaarselt WP-Crontroli korduvate ja järelejäänud ajastatud ülesannete puhastamiseks;
- Enne pluginate või teemade uuendamist varundage kindlasti oma andmed ja kui ilmnevad vead, tühistage kohe algsed versioonid.
Need kolm toimingut ei vaja keerulist tehnoloogiat ega kalleid arendajaid ning isegi algajad saavad nendega hõlpsalt hakkama, hoides samal ajal teie veebisaidi 5xx vigadest eemal ja säilitades stabiilse töö.
Iga teie veebisaidi stabiilne laadimine ja iga külastaja viibimine on väärtuslik vara, mida aja jooksul kogute.
Nüüdsest alates tuvastage need kolm süüdlast ja tehke igapäevast hooldust, et teie WordPressi veebisait mitte ainult ei kannaks teie rasket tööd, vaid suurendaks ka pidevalt liiklust ja tulu.
Kui teid häirivad praegu 5xx vead, proovige tõrkeotsinguks järgida selles artiklis toodud samme. Usun, et peagi saate neist probleemidest lahti, oma veebisaidi stabiilselt tööle panna ja saavutada pikaajalise kasvu.
Loodetavasti on teile abiks artikkel "4 peamist süüdlast 500, 502, 503 ja 504 vigade taga WordPressi veebisaitidel", mida jagati Chen Weiliangi blogis ( https://www.chenweiliang.com/ ).
Jaga julgelt seda artikli linki: https://www.chenweiliang.com/cwl-33968.html