Kā sagatavot WooCommerce lielai izpārdošanai: pārbaudes saraksts

Šis ir pārbaudes saraksts inženieriem, kas uztur WooCommerce veikalus pirms liela trafika notikuma: Black Friday, produkta palaišanas vai lielas kampaņas. Darbs sadalās trīs fāzēs, divas nedēļas pirms, pēdējās dienas un pati izpārdošana, un katrs solis šeit ir pietiekami konkrēts, lai to izpildītu terminālī.

Divas nedēļas pirms: atjaunini visu, bet tikai staging vidē

Sliktākais brīdis, kad atklāt spraudņu konfliktu, ir maksimālās slodzes laikā. Nokopē produkcijas vidi uz staging kopiju, veic tur visus atjauninājumus un tikai tad pārnes tās pašas versijas uz produkciju. Pēc tam iesaldē: nekādu versiju maiņu, līdz izpārdošana beidzas.

# staging kopijā
wp core update
wp core update-db
wp plugin update --all
wp theme update --all
wp wc update

Pēc atjaunināšanas izej naudas ceļu ar rokām: ieliec produktu grozā, ievadi kupona kodu, samaksā caur savu maksājumu vārteju testa režīmā un pārliecinies, ka pienāk pasūtījuma e-pasts. Ja tika atjaunināts maksājumu spraudnis, notestē katru maksājumu veidu, ko piedāvā tavs veikals, ne tikai kartes.

Pārliecinies, ka rezerves kopijas tiešām atjaunojas

Rezerves kopija, ko tu nekad neesi atjaunojis, ir pieņēmums, nevis rezerves kopija. Paņem jaunāko pilno kopiju, failus plus datubāzi, atjauno to atsevišķā testa vidē un palaid vietni no tās.

# testa vidē
wp db import nightly_dump.sql
wp db check
wp db query "SELECT COUNT(*) FROM wp_posts WHERE post_type='shop_order';"

Ja ieslēgta High-Performance Order Storage (HPOS) pasūtījumu glabāšana, skaiti tabulu wp_wc_orders. Skaitlim jāsakrīt ar produkciju. Ieplāno vēl vienu momentuzņēmumu stundu pirms izpārdošanas sākuma, lai atkāpšanās punkts ir dažas minūtes, nevis dienu vecs.

Slodzes tests kases lapai, nevis sākumlapai

Kešota sākumlapa iztur gandrīz visu, tāpēc šis skaitlis neko nepierāda. Grozs un kase apiet lapu kešatmiņu un katrā pieprasījumā trāpa PHP un datubāzē. Uzraksti skriptu reālajai plūsmai, pievieno grozam, atver grozu, ielādē kasi, un palaid to pret staging vidi ar rīku kā k6:

k6 run --vus 50 --duration 5m checkout-flow.js

Kamēr tests darbojas, skaties uz serveri, nevis testa izvadi:

mysqladmin extended-status | grep -E "Threads_(connected|running)"
tail -f /var/log/mysql/slow.log
grep max_children /var/log/php8.2-fpm.log

Atrodi punktu, kur atbildes laiki sāk augt, un mērķē noturēt 2-3x no gaidāmā maksimuma. Parastie labojumi atdeves secībā: palielini pm.max_children, cik atļauj RAM, ieslēdz pastāvīgu objektu kešatmiņu un indeksē vai pārraksti to, ko lēno vaicājumu žurnāls rāda atkārtoti.

Pēdējās dienas: attēli, spraudņi, kešatmiņas noteikumi

Izej cauri kataloga attēliem un jaunajiem baneriem: samazini līdz izmēriem, ko tēma tiešām rāda, saspied un atdod WebP, kur iespējams.

cwebp -q 82 banner.png -o banner.webp

Tad noņem svaru, kas izpārdošanas laikā nav vajadzīgs:

• Uz šo nedēļu atslēdz heatmap rīkus, sesiju ierakstītājus un sekundāros mārketinga pikseļus. Katrs no tiem pievieno front-end svaru un papildu admin-ajax vai REST pieprasījumus. Atstāj vienu vieglu analītikas rīku.
• Pārliecinies, ka lapu kešatmiņa izslēdz groza, kases un konta lapas un tiek apieta, tiklīdz parādās WooCommerce sesijas sīkdatne.

# nginx fastcgi-cache piemērs
if ($request_uri ~* "/(cart|checkout|my-account)") { set $skip_cache 1; }
if ($http_cookie ~* "woocommerce_items_in_cart|wp_woocommerce_session") { set $skip_cache 1; }

Pārbaudi no ārpuses: curl -I https://shop.example/checkout/ katrā pieprasījumā jārāda BYPASS vai MISS kešatmiņas galvene. Kešota kases lapa sajauc klientu grozus un salauž nonces, un tas ir daudz sliktāk nekā lēna lapa.

Sesiju un datubāzes noskaņošanas pamati

Pirmkārt, cron. WooCommerce tīra savu wp_woocommerce_sessions tabulu un darbina ieplānotās darbības caur WP-Cron, kas iedarbojas no lapu skatījumiem un zem slodzes uzvedas slikti. Atslēdz to ar define('DISABLE_WP_CRON', true); failā wp-config.php un darbini no sistēmas crona:

*/5 * * * * wp --path=/var/www/shop cron event run --due-now

Otrkārt, options tabula. Izdzēs beigušos transientus un pārbaudi, cik daudz datu ielādējas automātiski katrā pieprasījumā; zem aptuveni 1 MB ir veselīgi:

wp transient delete --expired
wp db query "SELECT SUM(LENGTH(option_value))/1024/1024 AS autoload_mb FROM wp_options WHERE autoload='yes';"

Treškārt, pats MySQL. Uzstādi innodb_buffer_pool_size pietiekami lielu, lai ietilptu darba datu kopa, salāgo max_connections ar PHP-FPM procesu skaitu un atstāj lēno vaicājumu žurnālu ieslēgtu visu izpārdošanu, lai redzi, kas sāp.

Izpārdošanas laikā: monitorē, neizvieto neko jaunu

Iesaldē visu. Nekādu deploy, nekādas spraudņu slēgšanas aiz ziņkārības, nekādu eksperimentu ar iestatījumiem. Vienīgās atļautās izmaiņas ir tās, kas jau ierakstītas tavā degradācijas plānā: kurus spraudņus atslēgsi pirmos, ja slodze kāpj, un kāds ir rezerves variants, ja maksājumu vārteja sāk klibot.

Seko četriem skaitļiem: PHP-FPM aktīvie procesi pret pm.max_children, MySQL Threads_running, diska vieta, jo žurnāli un sesijas aug ātri, un pasūtījumi minūtē. Pēkšņs pasūtījumu tempa kritums pie normālas plūsmas parasti nozīmē, ka kase ir salūzusi, un brīdinājumam jāatnāk no monitoringa, pirms klients uzraksta e-pastu. Ja kases kļūdas strauji aug un cēloni ātri atrast nevari, atjauno pārbaudīto momentuzņēmumu: tieši tāpēc tas eksistē.

Pārbaudes saraksts

1. Nokopē produkciju uz staging, 14 dienas pirms.
2. Atjaunini staging vidē kodolu, spraudņus, tēmas un WooCommerce datubāzi, tad notestē pilnu pirkumu.
3. Pārnes tās pašas versijas uz produkciju un iesaldē visus atjauninājumus.
4. Atjauno jaunāko rezerves kopiju atsevišķā vidē un pārbaudi pasūtījumu skaitu.
5. Slodzes testē skriptēto kases plūsmu, līdz noturi 2-3x no gaidāmā maksimuma.
6. Samazini un saspied attēlus, atdod WebP.
7. Atslēdz heatmap rīkus, sesiju ierakstītājus un sekundāros mārketinga pikseļus.
8. Ar curl pārbaudi kešatmiņas izņēmumus groza, kases un konta lapām.
9. Pārliecinies, ka darbojas pastāvīga objektu kešatmiņa.
10. Izdzēs beigušos transientus un pārbaudi autoload datu apjomu.
11. Pārcel WP-Cron uz sistēmas crona ierakstu.
12. Pārskati innodb_buffer_pool_size, max_connections un lēno vaicājumu žurnālu.
13. Uztaisi svaigu momentuzņēmumu stundu pirms izpārdošanas sākuma.
14. Izpārdošanas laikā: seko FPM, MySQL, diskam un pasūtījumu tempam, un neizvieto neko.

Ja negribi visu šo steku uzturēt pats, mūsu WordPress hostings mūsu pašu Rīgas datu centrā jau iekļauj servera puses kešatmiņu, Redis objektu kešatmiņu un ikdienas rezerves kopijas, kas noņem no šī saraksta labu daļu, pirms tu vispār sāc.