मिरर रोटेशन बदलता है कि Squid क्या दोबारा उपयोग कर सकता है

दो क्लाइंट Squid के ज़रिए वही RPM डाउनलोड करते हैं, लेकिन दूसरा स्थानांतरण फिर भी किसी मिरर तक पहुँचता है। पूर्ण अनुरोध URL की तुलना करें:

http://mirror-a.example.net/packages/tool-1.0.rpm
http://mirror-b.example.net/packages/tool-1.0.rpm

पैकेज के फ़ाइल नाम मेल खाते हैं; उनके लक्ष्य URI अलग हैं। HTTP कैश कुंजियों में कम से कम अनुरोध विधि और लक्ष्य URI शामिल होते हैं, इसलिए मेल खाते पैकेज चेकसम इन प्रविष्टियों को स्वतः नहीं जोड़ते।

Yum और DNF एक निश्चित baseurl उपयोग कर सकते हैं या mirrorlist और metalink के ज़रिए मिरर खोज सकते हैं। इसलिए समान इंस्टॉलेशन अलग डाउनलोड URL चुन सकते हैं।

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

जाँचें कि ऑब्जेक्ट कैशिंग उपलब्ध है या नहीं

सामान्य HTTPS CONNECT टनल के भीतर, Squid HTTP कैशिंग के लिए RPM प्रतिक्रिया का मुख्य भाग नहीं देख सकता। कोई सामान्य मिरर होस्टनाम इसे नहीं बदलेगा। HTTPS रिपॉज़िटरी को एन्क्रिप्टेड रखें।

जिन प्रतिक्रियाओं को Squid कैश कर सकता है, उनके लिए पुनः उपयोग अब भी ताज़गी, अनुरोध और प्रतिक्रिया निर्देशों तथा स्थानीय कैश नीति पर निर्भर करता है। चुना गया URL, यह कि लेन-देन दृश्यमान HTTP था या एन्क्रिप्टेड टनल, और उसका कैश परिणाम दर्ज करें ताकि चूक की व्याख्या हो सके।