WooCommerce veikals, kas ar 300 precēm strādāja raiti, pie 5000 precēm bieži kļūst lēns. Kategoriju lapas ielādējas vairākas sekundes, preces saglabāšanas laikā administrācijas panelis uz brīdi iesalst, bet importi velkas līdz naktij. Pirmā doma parasti ir pāriet uz jaudīgāku hostingu. Dažreiz tas palīdz uz mēnesi. Biežāk iemesls ir tas, kā WooCommerce glabā datus, un spēcīgāks serveris to tikai nomaskē, līdz katalogs atkal izaug.

Īsumā#

WooCommerce lielāko daļu preču datu, piemēram, cenu, SKU un krājumu statusu, glabā WordPress vispārīgajā tabulā wp_postmeta: katra vērtība ir atsevišķa rinda, un papildu rindas pievieno arī spraudņi. Veikalā ar tūkstošiem preču un variantu šajā tabulā uzkrājas simtiem tūkstošu rindu vai vairāk. Filtrēšana, kārtošana un meklēšana pēc vērtībām, ko neapkalpo WooCommerce uzmeklēšanas tabulas, liek datubāzei šo tabulu vairākkārt savienot pašai ar sevi, un indeksi šādu vaicājumu pilnībā neglābj.

Agrāk pasūtījumi tika glabāti tajā pašā struktūrā. Tagad WooCommerce piedāvā High-Performance Order Storage (HPOS), kas pasūtījumus pārceļ uz atsevišķām tabulām, taču preču dati paliek vecajā vietā. Tāpēc liels WooCommerce veikals parasti ir lēns trīs iemeslu dēļ vienlaikus: preču vaicājumi wp_postmeta tabulā, lapas, ko nevar saglabāt kešatmiņā, un fona darbi, kas ar apmeklētājiem sacenšas par to pašu serveri. Pirms kaut ko mainīt, izmēriet, kurš no tiem ir lielākais.

Vispirms noskaidrojiet, ko nozīmē "lēns"#

Ar lēnu veikalu parasti saprot četras dažādas problēmas, un to cēloņi atšķiras.

Kategoriju un meklēšanas lapas apmeklētājiem ielādējas lēni.
Preču lapas ir ātras, bet grozs un pasūtījuma noformēšana strādā ar aizkavi.
Lēni strādā administrācijas panelis, īpaši pasūtījumu saraksts un preču rediģēšana.
Importi, atlikumu atjaunināšana vai preču plūsmas ilgst stundām vai pārtrūkst.

Pierakstiet, ko tieši novērojat un kurā diennakts laikā. Ja veikals ir lēns tikai no diviem līdz četriem naktī, vainīgs ir kāds ieplānots darbs, nevis hostings.

Kur patiesībā paiet laiks#

Preču dati atslēgu un vērtību tabulā

WooCommerce preču datus, piemēram, cenu, SKU un krājumu statusu, glabā wp_postmeta tabulas rindās, un tēmas ar spraudņiem pievieno daudz savu rindu pielāgotiem laukiem. Cenai, krājumiem un SKU WooCommerce uztur atsevišķas uzmeklēšanas tabulas, lai paātrinātu biežāk izmantoto kārtošanu un filtrēšanu. Savukārt filtri pēc spraudņu pievienotiem laukiem un daži atribūtu filtri joprojām pārvēršas vaicājumos, kas katrai kategorijas precei vairākkārt savieno wp_postmeta vai taksonomiju tabulas.

Ar dažiem simtiem preču to nemana. Ar desmitiem tūkstošu variantu tā var kļūt par lēnāko lapas daļu. Filtru spraudņi, kas paši skaita preces pie katras vērtības, piemēram, "Sarkans (24)", šo darbu atkārto katrai filtra vērtībai lapā.

Pasūtījumi, kas vēl glabājas pa vecam

Vecākos veikalos un tajos, kas gadiem ilgi tikuši atjaunināti, pasūtījumi bieži joprojām atrodas ierakstu tabulās. WooCommerce paša 2023. gada HPOS testos pasūtījumu izveide pēc pārejas uz atsevišķām tabulām bija aptuveni piecas reizes ātrāka, un arī filtrēšana administrācijas sarakstā strādāja ievērojami ātrāk. Pirkuma noformēšanā ieguvums bija mazāks, aptuveni 1,5 reizes. Jaunām instalācijām HPOS ir ieslēgts pēc noklusējuma kopš WooCommerce 8.2.

Pašreizējo iestatījumu var apskatīt sadaļā WooCommerce, Settings, Advanced, Features. Pirms pārslēgšanas jāpārbauda, vai ar jauno glabāšanas veidu sader visi spraudņi, kas lasa pasūtījumus, un vispirms tas jāizmēģina veikala kopijā.

Lapas, ko nevar saglabāt kešatmiņā

Lapu kešatmiņa apmeklētājam atdod jau sagatavotu lapas kopiju, nevis veido to katru reizi no jauna. Tas noņem lielāko daļu slodzes no kategoriju un preču lapām. Grozam, pasūtījuma noformēšanai un klientiem, kas ir pieteikušies kontā, tā nedarbojas. Turklāt dažas tēmas un spraudņi neļauj saglabāt kešatmiņā nevienu lapu, jo uzstāda sīkdatnes vai pievieno katram apmeklētājam personalizētus fragmentus. Ja lapas reti tiek atdotas no kešatmiņas, serveris katru lapu veido no nulles.

Fona darbi dienas vidū

WordPress ieplānotos uzdevumus izpilda ar wp-cron, ko iedarbina apmeklētāju pieprasījumi. Tāpēc krājumu sinhronizācija, preču plūsmu ģenerēšana cenu salīdzināšanas vietnēm un e-pastu rindas darbojas tieši tad, kad veikalā ir pircēji. Noslogotā veikalā tas viegli palēnina pasūtījuma noformēšanu pašā nepiemērotākajā brīdī.

Pats serveris

Hostings ir svarīgs, taču noteiktā veidā. PHP procesu skaits nosaka, cik pieprasījumu bez kešatmiņas var apstrādāt vienlaikus. Pastāvīgā objektu kešatmiņa, piemēram, Redis, neļauj WordPress katrā pieprasījumā uzdot datubāzei tos pašus jautājumus. Neviens no tiem daudz nelīdzēs, ja katrā pieprasījumā tiek izpildīts vaicājums, kas ilgst divas sekundes.

Kā cēloni atrast aptuveni stundas laikā#

Izmēriet servera atbildes laiku atsevišķi no pārlūka. Ja HTML pirmais baits atnāk novēloti, problēma ir serverī. Ja HTML atnāk ātri, bet lapa tik un tā šķiet lēna, vaina ir attēlos, skriptos vai tēmā.
Veikala testa kopijā uzstādiet spraudni Query Monitor un atveriet lēnu kategorijas lapu un pasūtījumu sarakstu administrācijā. Tas parādīs lēnākos datubāzes vaicājumus un to, kurš spraudnis tos izpilda.
Uz vienu diennakti ieslēdziet datubāzes lēno vaicājumu žurnālu. Tā redzēsiet, kuri vaicājumi ir lēni reālas slodzes apstākļos, nevis tikai tie, ko pārbaudījāt paši.
Hostinga panelī vai kešatmiņas spraudnī apskatiet, cik bieži lapas atdod kešatmiņa.
Uzskaitiet ieplānotos uzdevumus un to izpildes laikus. Meklējiet smagus darbus darba laikā.

Beigās jums jāspēj pateikt, kurš no iepriekš minētajiem cēloņiem aizņem visvairāk laika. Labojiet vispirms to.

Labojumi secībā, kādā tie parasti atmaksājas#

Izvediet smagos ieplānotos darbus no apmeklētāju plūsmas: atslēdziet wp-cron palaišanu lapas ielādes brīdī, palaidiet to ar servera uzdevumu plānotāju un importus ieplānojiet klusajām stundām.
Panāciet, lai lapu kešatmiņa darbojas visām lapām, kurām to var izmantot, un noņemiet visu, kas neļauj šīs lapas saglabāt kešatmiņā.
Pievienojiet pastāvīgo objektu kešatmiņu.
Ieslēdziet HPOS pēc tam, kad veikala kopijā pārbaudīta spraudņu saderība.
Filtru un meklēšanas spraudņus, kas katrā pieprasījumā vaicā preču metadatus, nomainiet pret tādiem, kas izmanto indeksu, vai pret atsevišķu meklēšanas pakalpojumu.
Noņemiet neizmantotos spraudņus. Katrs aktīvs spraudnis ielādējas katrā pieprasījumā.
Tikai pēc tam salīdziniet hostinga plānus un izvēlieties jaudu pēc pirmajā solī iegūtajiem mērījumiem.

Strādājiet veikala testa kopijā un glabājiet rezerves kopiju, kuru vismaz vienreiz esat reāli atjaunojis. Izmaiņas pasūtījumu glabāšanā un kešatmiņā var sabojāt pasūtījuma noformēšanu tā, ka to pamana tikai tad, kad kāds mēģina samaksāt.

Kad problēma ir pati platforma#

Ja katalogs ir liels, katru dienu mainās no ERP vai noliktavas sistēmas un veikals pēc visiem šiem soļiem joprojām balstās uz daudziem spraudņiem, WooCommerce uzturēšana ātrā stāvoklī var izmaksāt vairāk nekā pāreja uz citu platformu. Tas ir uzņēmējdarbības lēmums ar saviem riskiem: pārejas laikā jāsaglabā klientu konti, adreses un pozīcijas meklētājprogrammās. Par to, kas netiek pārnests automātiski, lasiet rakstā par pāreju no WooCommerce uz Shopify.

Ja atlikumi veikalā nesakrīt ar noliktavu, pirms vainot ātrdarbību izlasiet, kāpēc interneta veikala atlikumi vairs nesakrīt ar noliktavu.

Nevo izstrādā un uztur interneta veikalus. Kā projekts sākas, aprakstīts lapā interneta veikalu izstrāde.

Kāpēc WooCommerce veikals kļūst lēns, pieaugot preču skaitam