एका हाय-ट्रॅफिक व्हिडिओ साइटने संपूर्ण-पेज कॅशिंगकडून (whole-page caching) Varnish आणि Edge Side Includes (ESI) वापरून फ्रॅगमेंट कॅशिंगकडे (fragment caching) वळल्यामुळे, त्यांच्या ट्रेंडिंग-पेज फीडसाठी लागणाऱ्या डेटाबेस क्वेरीज प्रति मिनिट ४,००० वरून ५० च्या खाली आणल्या आणि ९५ व्या पर्सेंटाईलचा (95th-percentile) रिस्पॉन्स टाइम ३८० ms वरून ४० ms पर्यंत कमी केला.

साइटला वेगळ्या कॅश स्ट्रॅटेजीची गरज का होती

दिवसातील सर्वाधिक पाहिलेले क्लिप्स दाखवणारे फ्रंट पेज एका प्रदेशातील जवळजवळ प्रत्येक व्हिजिटरसाठी सारखेच दिसते: १० लाख युजर्ससाठी सुमारे ९५ टक्के HTML सारखेच असते, तर उर्वरित ५ टक्के भागात लॉग-इन केलेल्या युजरचे नाव किंवा सर्च बॉक्स यांसारखा वैयक्तिक डेटा असतो. इंजिनिअरिंग टीमसमोर दोन नको असलेले पर्याय होते:

  • संपूर्ण पेज कॅश करणे आणि लॉग-इन केलेल्या युजर्सना जुना (stale) वैयक्तिक डेटा दाखवण्याचा धोका पत्करणे.
  • कॅश पूर्णपणे बायपास करणे आणि प्रत्येक रिक्वेस्टमुळे डेटाबेसवर ताण येणे.

दोन्ही पद्धतींमुळे युजर एक्सपिरियन्स खराब होत होता. टीमने ESI चा वापर करण्याचा निर्णय घेतला, ही एक अशी तंत्रज्ञान पद्धत आहे ज्यामध्ये रिव्हर्स-प्रॉक्सी (reverse-proxy) नेटवर्कच्या एजवर (edge) स्वतंत्रपणे कॅश केलेल्या फ्रॅगमेंट्सपासून एक पेज तयार करू शकते.

फ्रॅगमेंट कॅशिंग कसे कार्यान्वित केले गेले

ओपन-सोर्स HTTP एक्सिलरेटर, Varnish ने पेजला तीन बदलता येण्याजोग्या भागांसह एका 'स्केलेटन' (skeleton) प्रमाणे मानले:

  • व्हिडिओ ग्रिड (Video grid) – ट्रेंडिंग व्हिडिओंची महागडी, प्रदेश-व्यापी यादी. हे वारंवार बदलत असल्याने आणि प्रत्येक अनामित (anonymous) व्हिजिटरसाठी सारखेच असल्याने ६० सेकंदांसाठी कॅश केले जाते.
  • लँग्वेज स्विचर (Language switcher) – एक स्टॅटिक UI घटक जो क्वचितच बदलतो. २४ तासांसाठी कॅश केला जातो.
  • हेडर (Header) – एकमेव खरोखर वैयक्तिक फ्रॅगमेंट (युजरचे नाव, अवतार, नोटिफिकेशन्स). हे कधीही कॅश केले जात नाही; Varnish प्रत्येक वेळी रिक्वेस्ट ॲप्लिकेशन सर्व्हरकडे पाठवते.

जेव्हा एखादी रिक्वेस्ट येते, तेव्हा Varnish कॅश केलेले स्केलेटन सर्व्ह करते, त्याच्या लोकल स्टोअरमधून दोन कॅश केलेले फ्रॅगमेंट्स घेते आणि बॅकएंडमधून लाईव्ह हेडर समाविष्ट करते.

महत्त्वाचे आकडेवारी

बदल केल्यानंतर:

  • ट्रेंडिंग पेजसाठीचा डेटाबेस लोड प्रति मिनिट ४,००० क्वेरीजवरून ५० च्या खाली आला.
  • ९५ व्या पर्सेंटाईलचा लॅटन्सी (latency) ३८० ms वरून ४० ms पर्यंत कमी झाला.

रोलआउटमधून तीन व्यावहारिक धडे

१. ग्रेस पिरीयड्स (Grace periods) कॅश मिस (cache misses) कमी करतात जेव्हा एखाद्या फ्रॅगमेंटचा TTL संपतो, तेव्हा Varnish सामान्यतः नवीन कंटेंट मिळवण्यासाठी थांबते, ज्यामुळे लॅटन्सीमध्ये अचानक वाढ होते आणि एकाच वेळी अनेक बॅकएंड कॉल्सचा "thundering herd" परिणाम होऊ शकतो. ग्रेस पिरीयड कॉन्फिगर केल्यामुळे, Varnish बॅकग्राउंडमध्ये शांतपणे कॅश रिफ्रेश करत असताना जुना (stale) फ्रॅगमेंट सर्व्ह करणे सुरू ठेवते. युजर्सना कोणताही विलंब जाणवत नाही; बॅकएंडला स्थिर आणि व्यवस्थापित करण्यायोग्य रिक्वेस्ट रेट मिळतो.

२. अनामित फ्रॅगमेंट्ससाठी कुकीज काढून टाका (Strip cookies) प्रत्येक रिक्वेस्टला जोडलेल्या कुकीजमुळे Varnish प्रत्येक रिक्वेस्टला युनिक (unique) मानते, ज्यामुळे कॅश हिट्सचा फायदा मिळत नाही. टीमने व्हिडिओ ग्रिड आणि लँग्वेज स्विचरसाठी कुकीज काढून टाकल्या, ज्यामुळे ते फ्रॅगमेंट्स आक्रमकपणे (aggressively) कॅश करणे शक्य झाले. केवळ हेडर फ्रॅगमेंटमध्ये कुकीज असतात, ज्यामुळे कॅश कार्यक्षमता कमी न करता वैयक्तिकीकरण (personalization) टिकवून ठेवले जाते.

३. सरोगेट कीज (Surrogate keys) त्वरित पजिंग (purging) सक्षम करतात कधीकधी एखादा व्हिडिओ त्वरित काढून टाकणे आवश्यक असते—उदा. कॉपीराइट कारणांमुळे. ६० सेकंदांचा TTL संपण्याची वाट पाहणे स्वीकारार्ह नाही. प्रत्येक कॅश केलेल्या फ्रॅगमेंटला मूळ व्हिडिओ आयडी दर्शवणारी 'सरोगेट की' (surrogate key) देऊन, टीम एकच 'पर्ज' (purge) कमांड देते, जी प्रत्येक एज नोडवरील त्या विशिष्ट व्हिडिओच्या सर्व कॉपीज त्वरित अवैध (invalidate) करते. यामुळे संपूर्ण कॅश स्कॅन करण्याची गरज पडत नाही आणि साइट नियमांचे पालन करते.

निष्कर्ष: Varnish आणि ESI सह फ्रॅगमेंट कॅशिंगमुळे एक मोनोलिथिक (monolithic) आणि डेटाबेसवर अवलंबून असलेले पेज हलक्या आणि पुन्हा वापरण्यायोग्य भागांच्या संचात रूपांतरित होते, ज्यामुळे युजरचे वैयक्तिकीकरण टिकवून ठेवताना बॅकएंड लोड आणि लॅटन्सीमध्ये मोठी घट होते.