Squid का कौन-सा बाइट काउंटर ट्रैफ़िक कोटा को इस्तेमाल करना चाहिए?
Squid लॉग फ़ील्ड जोड़ने से पहले तय करें कि प्रॉक्सी कोटा उत्तर, अनुरोध, अपस्ट्रीम बॉडी या एक्सेस-लिंक ट्रैफ़िक मापता है।
“हर उपयोगकर्ता को दस गीगाबाइट दें” तब तक सटीक लगता है जब तक दो रिपोर्टें मेल नहीं खातीं। एक ने क्लाइंट को भेजे गए उत्तर जोड़े थे; दूसरे ने अपस्ट्रीम से लाए गए बाइट गिने थे। दोनों संभवतः अपने चुने हुए फ़ील्ड की सही रिपोर्ट दे रहे हों।
Squid के लॉग प्रारूप में अलग काउंटर हैं:
| फ़ील्ड | प्रलेखित माप |
|---|---|
%<st | अनुकूलन के बाद क्लाइंट को भेजा गया कुल उत्तर ट्रैफ़िक |
%>st | क्लाइंट से प्राप्त अनुरोध का कुल आकार, चंक्ड-एन्कोडिंग के बाइट छोड़कर |
%<bs | अगले हॉप से प्राप्त HTTP-समतुल्य संदेश-बॉडी बाइट, प्रलेखित अपवादों सहित |
Squid के मूल लॉग का बाइट कॉलम क्लाइंट-उत्तर काउंटर का उपयोग करता है। यह वादा नहीं है कि मान सहेजी गई फ़ाइल की लंबाई के बराबर है, और यह उस हर ईथरनेट या IP बाइट का माप भी नहीं है जो कोई प्रदाता वसूलता है।
कैश हिट अंतर दिखाते हैं: Squid नई अपस्ट्रीम फ़ेच किए बिना उत्तर भेज सकता है। अधिक अपलोड वाला काम दूसरा अंतर दिखाता है: केवल उत्तर गिनने पर अनुरोध की दिशा बजट से बाहर रह जाती है।
CONNECT के लिए प्रॉक्सी सुरंग के भीतर की हर एन्क्रिप्टेड फ़ाइल या पृष्ठ को समझे बिना रिले किए गए ट्रैफ़िक का हिसाब कर सकता है। पर वह सुरंग के कुल बाइट को डाउनलोड किए गए एप्लिकेशन ऑब्जेक्ट की सटीक सूची में नहीं बदल सकता।
काउंटर के पास कोटा अनुबंध लिखें: दिशा, अवलोकन बिंदु, लेखा अवधि और पहचान। फिर लॉग प्रारूप का संस्करण रिपोर्टों के साथ रखें। बाइट का अर्थ क्या है, इस पर मतभेद को अनुमानित सुधार गुणक से हर मान गुणा करके “ठीक” नहीं करना चाहिए। प्रवर्तन के लिए, पूर्ण किए गए लेन-देन के योग जीवंत उपयोग से पीछे रह सकते हैं.