Tovuti ya video yenye trafiki kubwa ilipunguza maswali ya hifadhidata (database queries) kwa ajili ya sehemu ya trending-page kutoka maswali 4,000 kwa dakika hadi chini ya 50, na kupunguza muda wa mwitikio wa asilimia ya 95 (95th-percentile response time) kutoka ms 380 hadi ms 40 kwa kuhamia kutoka 'whole-page caching' kwenda 'fragment caching' kwa kutumia Varnish na Edge Side Includes (ESI).

Kwa nini tovuti ilihitaji mkakati tofauti wa cache

Ukurasa wa mbele unaoonyesha vipande vya video vilivyotazamwa zaidi kwa siku hiyo unaonekana vilevile kwa karibu kila mgeni katika eneo fulani: takriban asilimia 95 ya HTML ni sawa kwa watumiaji milioni moja, wakati asilimia 5 iliyobaki hubeba data za kibinafsi kama vile jina la mtumiaji aliyeingia au kisanduku cha utafutaji. Timu ya uhandisi ilikabiliwa na chaguzi mbili zisizovutia:

  • Kuweka cache ukurasa mzima na kujihatarisha kuonyesha data za kibinafsi zilizopitwa na wakati kwa watumiaji walioingia.
  • Kupuuza cache kabisa na kuruhusu kila ombi (request) lishambulie hifadhidata.

Njia zote mbili ziliharibu uzoefu wa mtumiaji. Timu iligeukia ESI, mbinu inayoruhusu reverse-proxy kuunganisha ukurasa kutoka kwa vipande vilivyowekwa kwenye cache (cached fragments) kwa kutumia sehemu za mwisho za mtandao (edge of the network).

Jinsi fragment caching ilivyowekwa

Varnish, kichochezi cha HTTP cha chanzo huru (open-source), ilichukulia ukurasa kama mifupa (skeleton) yenye vipande vitatu vinavyoweza kubadilishwa:

  • Video grid – orodha ghali ya video zinazovuma (trending videos) kwa kiwango cha eneo. Inahifadhiwa kwenye cache kwa sekunde 60 kwa sababu inabadilika mara kwa mara lakini ni sawa kwa kila mgeni asiye na akaunti.
  • Language switcher – kipengele cha UI ambacho hakibadiliki mara kwa mara. Inahifadhiwa kwenye cache kwa saa 24.
  • Header – kipande pekee ambacho ni cha kibinafsi kabisa (jina la mtumiaji, picha ya wasifu, arifa). Hakihifadhiwi kwenye cache; Varnish hupeleka ombi kwa seva ya programu kila wakati.

Ombi linapofika, Varnish hutoa mifupa iliyowekwa kwenye cache, inachukua vipande viwili vilivyowekwa kwenye cache kutoka kwenye hifadhi yake ya ndani, na kuingiza header ya moja kwa moja kutoka kwa backend.

Namba muhimu

Baada ya mabadiliko:

  • Mzigo wa hifadhidata kwa ukurasa wa trending ulipungua kutoka maswali 4,000 kwa dakika hadi chini ya 50.
  • Latency ya asilimia ya 95 ilipungua kutoka ms 380 hadi ms 40.

Mafunzo matatu ya vitendo kutoka kwa utekelezaji huu

1. Vipindi vya neema (Grace periods) hupunguza athari za kukosa cache Wakati TTL ya kipande fulani inapopita muda wake, Varnish kwa kawaida ingesimama ili kupata maudhui mapya, na kusababisha ongezeko la ghafla la latency ambalo linaweza kusababisha "thundering herd" ya simu za backend za wakati mmoja. Kwa kusanidi kipindi cha neema (grace period), Varnish inaendelea kutoa kipande kilichopitwa na wakati wakati ikiwa inafanya upya cache kwa siri nyuma ya pazia. Watumiaji hawaoni kusimama; backend huona kiwango cha maombi kinachoweza kudhibitiwa.

2. Ondoa kuki (cookies) kwa vipande visivyo na utambulisho Kuki zinazoambatana na kila ombi husababisha Varnish kuchukulia kila ombi kama la kipekee, jambo linalofuta faida za cache hits. Timu iliondoa kuki kwa ajili ya video grid na language switcher, na kuruhusu vipande hivyo kuhifadhiwa kwenye cache kwa ukali zaidi. Ni kipande cha header pekee ambacho hubeba kuki, hivyo kuhifadhi ubadilishaji wa kibinafsi bila kusaliti ufanisi wa cache.

3. Surrogate keys huruhusu kufuta (purging) papo hapo Wakati mwingine video lazima iondolewe mara moja—kwa mfano, kwa sababu za hakimiliki. Kusubiri TTL ya sekunde 60 iishe haikubaliki. Kwa kuweka kila kipande kilichowekwa kwenye cache na surrogate key inayoakisi ID za video husika, timu hutoa amri moja ya kufuta (purge command) ambayo inafuta nakala zote za video fulani papo hapo kwenye kila edge node. Hii inazuia kufanya usafi wa cache mzima na kuifanya tovuti kuzingatia sheria.

Muhtasari: Fragment caching kwa kutumia Varnish na ESI inageuza ukurasa mmoja mkubwa uliotegemea hifadhidata kuwa seti ya vipande vyepesi vinavyoweza kutumika tena, ikipunguza mzigo wa backend na latency huku ikihifadhi ubadilishaji wa kibinafsi wa kila mtumiaji.