मान लीजिए ब्राउज़र में कई वर्कर एक ही साइट के अलग-अलग पेज खोलते हैं। वे पेज एक ही स्टाइलशीट, लोगो और स्क्रिप्ट बंडल का संदर्भ देते हैं। साझा फ़ॉरवर्ड कैश पहले अनुरोध को बाद के वर्कर के लिए उपयोगी बना सकता है, जब प्रतिक्रियाएँ दोबारा इस्तेमाल की जा सकती हों।

अब कार्यभार बदलिए: हर वर्कर सिर्फ़ एक HTML दस्तावेज़ डाउनलोड करता है और उसके जुड़े संसाधन कभी लोड नहीं करता। साझा स्टाइलशीट अब भी मार्कअप में मौजूद है, लेकिन कोई वर्कर उसे नहीं माँगता। यह प्रॉक्सी की कैश हिट दर में कुछ नहीं जोड़ता।

उन अनुरोधों से शुरू करें जो आपका क्रॉलर वास्तव में करता है

पेज रेंडर करने वाला ब्राउज़र और उसका स्रोत लाने वाला HTTP क्लाइंट अलग-अलग अनुरोध-समुच्चय बनाते हैं। कैश डिज़ाइन चुनने से पहले उन समुच्चयों की जाँच करें।

कार्यभारसाझा पुन:उपयोग की संभावना
वर्कर बार-बार वही सार्वजनिक संपत्तियाँ लाते हैंउपयोगी जब ताज़गी और कैश-कुंजी नियम अनुमति दें
हर अनुरोध का अद्वितीय URL या प्रतिक्रिया प्रकार होता हैपुन:उपयोग के लिए कम ओवरलैप
पुन:उपयोग से पहले प्रतिक्रिया को फिर से सत्यापित करना पड़ता हैप्रतिक्रिया बाइट बचा सकता है, पर ऊपर की ओर यात्रा अब भी ज़रूरी है
वर्कर अपने स्थानीय कैश से अनुरोध पूरे कर रहे हैंवे अनुरोध शायद साझा प्रॉक्सी तक कभी न पहुँचें

सिर्फ़ URL की समानता पर्याप्त नहीं है। प्रतिक्रिया की ताज़गी नीति और Vary द्वारा नामित फ़ील्ड प्रस्तुतियों को अलग कर सकते हैं. निजी, संग्रहण-अयोग्य या प्रमाणित सामग्री के लिए लागू साझा-कैश नियम चाहिए; सिर्फ़ हिट संख्या बढ़ाने के लिए उसे एक ही सार्वजनिक परिणाम में मजबूर नहीं करना चाहिए।

सामान्य HTTPS CONNECT ट्रैफ़िक के लिए फ़ॉरवर्ड प्रॉक्सी एक एन्क्रिप्टेड सुरंग ले जाता है और उसके अंदर कैश करने योग्य कोई HTTP ऑब्जेक्ट नहीं होता. TLS निरीक्षण वाली तैनाती का भरोसा और प्रसंस्करण व्यवहार अलग होता है। ऑब्जेक्ट कैश उपलब्ध है या नहीं, यह आँकते समय वास्तविक मोड शामिल करें।

कैश हिट ऊपर की ओर जाने वाला अनुरोध टाल सकता है, जबकि चूक अब भी बिचौलिए के काम का भुगतान करती है। इच्छित कार्यभार के लिए पूरे हुए उपयोगी बाइट, ऊपर का ट्रैफ़िक और विलंबता की तुलना करें। थ्रेड संख्या समकालिकता बताती है; यह नहीं बताती कि वे थ्रेड कितनी पुन:प्रयोज्य सामग्री साझा करते हैं।

संबंधित लेख