Fekete péntek - TECHNIKAI útmutató a túléléshez - 1. rész - Lakk

Ez a cikk egy 3 cikkből álló sorozat része, amelyek célja az online áruházak fekete pénteken való túljutása.

ez az első rész
A 2. részben a CDN-ekről beszéltünk
Egy jövőbeni cikkben a párhuzamosításról - vagyis több szerver egyidejű használatáról - fogunk beszélni.

A fekete péntek már nagy esemény Romániában. Nem csak mi mondjuk ezt az iparágban, hanem az egész sajtóban. Ha a marketing és az értékesítés területén tevékenykedőknek van miért örülniük, akkor a műszaki osztályok emberei mindenképpen stresaИ> i az esemény. Voltunk.

Ebben az évben az Avanticart szerverek szinte tökéletesen mentek 1, nem voltak leállások és nagyon jó válaszidők (általában kevesebb, mint 500 milliszekundum). NEM Nem találtam ki újat. Csak sokat olvastam, kísérleteztem és összeállítottam a különféle technológiákat.

Ahogy mások által írtak segítettek nekünk, vissza akarunk adni valamit. Hisszük, hogy mindannyian csak a tanultak megosztásával léphetünk előre. E cikkünkkel szeretnénk segíteni a romániai fejlesztőknek és az e-kereskedelmi közösségnek abban, hogy túljussanak a közelgő fekete péntekeken.

Oké, hagyja el a történetet, és mondja el, mit tett

Röviden, 3 dolog vezetett a dolgok zökkenőmentes lebonyolításához:

Lakk - erős gyorsítótár
CDN képekhez és css/javascripthez
Kérelmek megosztása több szerveren

Ha Ön üzlet tulajdonosa az út elején, kérjük, ne feszélyezze a programozóját a fentiek mindegyikével. Nem mind a 3 elérhető bármelyik üzlet számára. A 2. pont valószínűleg elég.

Oké, vegyük mindegyiket külön-külön. Kezdjük Varnish-szal, mert valószínűleg ő az, aki "megmentette" az Avanticart helyzetét. A CDN és további kiszolgálók használatával hamarosan visszatérünk cikkekkel.

Lakk

A "normál" blogtól vagy webhelytől eltérően sokkal nehezebb gyorsítótárat tárolni egy online áruházban. Miért? Két fő ok:

mert nem tárolhatja gyorsítótárban a bevásárlókosarat. Erre az oldalra hivatkozunk:
mert a részvényeknek valós időben kell működniük

Valószínűleg a platformod már tartalmaz alapértelmezés szerint egy gyorsítótár-modult (a gyorsítótár több szinten is elvégezhető), de garantáljuk, hogy semmi sem éri el a Varnish-t. Íme a tipp: keressen egy lakk plugint a platformjához. Még akkor is, ha kerül (maga a plugin + a megvalósítás), látni fogja, hogy megéri. Ez nem csak a fekete péntek. Miért nem akar 100 ms válaszidőt egész évben?

Miért olyan hangos a lakk?

A lakk webszerverként működik, és ez az első interakció a látogatóval. Alapvetően lakkozzon az Apache/Nginx vagy bármely más webszerver előtt, és tároljon mindent, amit elkap. Így nagyon kevés alkalmazás fogyaszt erőforrásokat (adatbázis-kapcsolatok stb.).

A Varnish telepítése után a 6081-es porton fut. Alapértelmezés szerint módosítania kell a 80-as portra, különben elveszíti a szórakozást. Ehhez módosítani kell az/etc/default/lakish fájlt. Debian-t használunk, CentOS-hoz vagy más terjesztésekhez, a konfiguráció eltérhet.

A fenti fájlban talál egy olyan sort, mint:

Itt kell váltani -a: 6081 értékről -a: 80 értékre. Hasznos lenne TTL-t is beállítani a -t paraméter segítségével. Ezért ez a vonal valami hasonlóvá válik:

Oké, most, hogy megváltoztattuk a lakkot a lakkban, meg kell változtatnunk a portot a webszerveren is. Apache-ot használunk, ezért módosítjuk az /etc/apache2/ports.conf fájlt. Megváltoztatjuk a Listen 80 sort a Listen 8080-ra. Elméletileg ez elég, de ez attól függ, hogyan állítja be a virtuális házigazdákat. Indítsuk újra az Apache-t, majd a Vanish-t.

Eddig egyszerű volt, de még nincs kész. A lakk fut, de valószínűleg nem tárol semmit. Honnan lehet tudni, hogy gyorsítótárazunk-e? 2-3 alkalommal frissítsen egy oldalt. Ezután keresse meg a Firebug/Developer eszközöket.

Valószínűleg az Age fejléc nullát mutat. A jele annak, hogy nincs gyorsítótár.

Diétás problémák?

Valami fontos tudnivaló: A lakknak problémája van a süteményekkel. Nem tárol gyorsítótárat az oldalról, ha sütiket küld. Ezenkívül nem tárolja a gyorsítótárat, ha a kiszolgáló Cache-Control fejlécet küld, amelynek nincs gyorsítótár-értéke. Lássuk, hogyan oldjuk meg ezeket a problémákat.

Az Avanticart PHP-ben íródott, mint a piacon elérhető legtöbb nyílt forráskódú (vagy saját) e-kereskedelmi megoldás. Ha áruháza egy másik nyelven készült, biztosak vagyunk abban, hogy képes lesz hasonló megoldásokat találni.

Alapértelmezés szerint a PHP a Cache-Control fejlécet küldi, amikor elindítja a munkamenetet. A Firebug/Developer eszközökben ilyesmit láthat:

Megszabadulásához egyszerűen hívja meg a session_cache_limiter ('') parancsot; Session_start () előtt; . Legyen óvatos, hogyan adja hozzá ezt a kódot. Ha nyílt forráskódú platformot használ, akkor problémája lesz a jövőbeli frissítéssel, ha közvetlenül megváltoztatja a forráskódot. Írhat plugint, vagy megtalálhat egy beállítást.

Most, hogy ez a probléma megoldódott, nézzük meg, hogyan oldjuk meg a sütikkel. Érdekes részleteket találtam a Gyorsan oldalon. Alapvetően egy sor trükköt készítenek a sütik törlésére és fejléc formájában történő visszahelyezésre. Az /etc/varnish/default.vcl fájlt módosítani kell, hogy valami ilyesmit mutasson:

Úgy gondoljuk, hogy a kódban szereplő megjegyzések elegendőek, de vegye figyelembe, hogy egy munkamenet sütit keresünk APP_SESSID_ (valami) néven. Itt meg kell változtatnia a cookie nevét a platformján.

Egy másik fontos dolog, amit meg kell jegyezni, hogy a látogató első kérése mindig gyorsítótár nélkül érkezik az üzletbe. Ez a munkamenet süti fogadására szolgál.

A Fastly által javasolt verzióhoz képest ezt a részt kiegészítettük:

Vagyis nem akarjuk, hogy gyorsítótárba kerüljenek, ha a látogató a fizetés oldalon, a fiók oldalon van, vagy ha a kérelem .php fájlokra irányul (általában az Ajax kéri, mert a legtöbb URL SEO-barát, így nem ér véget .php-ben). Biztosan vannak olyan oldalai, amelyeket nem szabad gyorsítótárba helyezni. Meg kell határoznia őket, és ennek megfelelően módosítania kell a fájlt.

A Varnish újraindítása és 2-3 kérés végrehajtása után látnia kell a nulla nem kor fejlécet a Firebug/Developer eszközökben.

Ha ideér és megszabadul a diétás problémáitól, gratulálok, akkor a Lakkja meghízhat (hasi - sajnálom - gyorsítótárat hoz létre). Ha az Age fejléc továbbra is nulla értéket jelent, az azt jelenti, hogy valami nincs rendben. A folytatás előtt meg kell oldania ezt a problémát.

Aki megette a süteményeket?

Oké, most készül a gyorsítótár, de a sütik továbbra sem kerülnek vissza az áruház alkalmazásába. Ehhez létre kell hoznunk a $ _COOKIE változót a Varnish által beállított fejlécből.

És én hoztam létre ezt a funkciót:

Ismét ügyeljen arra, hogy a jövőbeni frissítéssel kapcsolatos problémák elkerülése érdekében legyen óvatos, ha ezt a funkciót írja/hívja.

A kosár, mint a kosárnál?

Szuper. Van gyorsítótárunk, vannak sütink. Csak egy probléma maradt: az egész oldalt tárolja, beleértve a kód azon részét is, amely megmutatja, hány termék van a bevásárlókosárban.

A teszteléshez privát módon/inkognitóban megnyithat egy új böngészőablakot. A második frissítéskor (az első soha nem kerül gyorsítótárba, emlékszel?) Az első böngészőben meglátja a kosarat.

A lakk egy speciális címkét ad nekünk, amelyet beilleszthetünk az oldalra. Tehát ahol van a bevásárlókosár, megadhatunk egy kódot, például:

Amikor Varnish meglátja ezt a kódot az oldalon, háttérkérést fog benyújtani az /esi_shopping_cart.php fájlhoz, kiveszi az eredményt és újraszerkeszti az oldalt, anélkül, hogy a látogató tudna róla.

Azért nem tesszük ide a /esi_shopping_cart.php fájlt, mert a megvalósítás platformonként eltérő, de egyszerű visszhang lehet néhány munkamenet-változó esetén.

Az ESI működéséhez észre kell venni, hogy a vcl_fetch alá a beresp.do_esi = true sort állítottam; .

Oké, minden tökéletesen megy, úgyhogy itt az ideje kihozni a sört a hidegből, igaz? Ne siess, eddig ez volt a könnyű rész.

Ezt a gyorsítótárat ki kell törölni. Az egyszerű módszer az egész gyorsítótár törlése az áruház bármilyen módosításakor. Ez nem jelentene problémát egy hétköznapon, de itt a fekete péntekről beszélünk. Ha minden paranccsal elkezdi törölni a teljes gyorsítótárat az állomány frissítéséhez, akkor problémája lesz. Ideális esetben csak annak a terméknek a gyorsítótárát kell törölnie, amelynek raktárkészlete megváltozott, és esetleg az adott termék kategória oldalát.

A gyorsítótár törléséhez néhány különleges kérést kell megadnia (PURGE/BAN a GET/POST helyett) a Lakkozáshoz. Ezeket a kéréseket többféleképpen lehet benyújtani, és további részletek megtalálhatók a dokumentációban. Inkább a BAN-t használjuk.

Az Avanticartnál, mivel ugyanazon a szerveren több üzlet is van, tudnunk kell, melyik áruházból akarjuk törölni a gyorsítótárát. Ezért néhány további fejlécet használunk (X-Ban-Host és X-Ban-Url). Módosítanunk kell az /etc/varnish/default.vcl fájlt a + fejlécek törléséhez.

Mivel ezek a kérések bárhonnan érkezhetnek, jobb, ha nem hagyjuk, hogy bárki törölje a gyorsítótárát. Ezt a sort adjuk hozzá a fájl elejéhez:

Ezután a vcl_recv függvényt a következőképpen módosítjuk:

Speciális fejlécek hozzáadásával módosítjuk a vcl_fetch függvényt:

És most újraindítjuk a Vanish-t, hogy kihasználjuk a változásokat.

Itt van a PHP funkció, amely kezeli a törlést:

Természetesen nagyon fontos, hogy mikor és hol használja ezt a funkciót, és hatással lehet a teljesítményre. A $ url rendszeres kifejezéseket megadhat. Így az összes gyorsítótár törléséhez hívhatjuk a clearVarnishCache ($ host, '. *');

Most már tényleg készen áll. Ha úgy gondolja, hogy elmulasztottunk valamit, írjon nekünk egy megjegyzést. Ha pedig jövőben szeretne cikkeket kapni a CDN-ekről és több szerverről, iratkozzon fel.

az egyik vevőt rossz beállítás érte, ami furcsa bevásárlókocsi-viselkedéshez vezetett (Emilian, még egyszer elnézést kérünk).