«प्रत्येक प्रयोगकर्तालाई दस गिगाबाइट दिनुहोस्» भन्ने कुरा दुई प्रतिवेदन नमिलेसम्म सटीक सुनिन्छ। एउटाले ग्राहकहरूलाई पठाइएका जवाफ जोड्यो; अर्कोले अपस्ट्रिमबाट ल्याइएका बाइट गन्यो। दुवैले आफूले छानेको फिल्ड सही रूपमा रिपोर्ट गरिरहेका हुन सक्छन्।

Squid को लग ढाँचामा छुट्टाछुट्टै काउन्टरहरू छन्:

फिल्डअभिलेखित मापन
%<stअनुकूलनपछि ग्राहकलाई पठाइएको कुल जवाफ ट्राफिक
%>stग्राहकबाट प्राप्त कुल अनुरोध आकार, chunked इन्कोडिङ बाइटबाहेक
%<bsअर्को हपबाट प्राप्त HTTP-समान सन्देश बडी बाइट, अभिलेखित अपवादसहित

Squid को मूल लगको bytes स्तम्भले ग्राहक जवाफ काउन्टर प्रयोग गर्छ। त्यो मान सुरक्षित फाइलको लम्बाइसँग बराबर हुन्छ भन्ने वाचा होइन, र ISP ले लिने प्रत्येक Ethernet वा IP बाइटको मापन पनि होइन।

क्यास हिटहरूले भिन्नता देखाउँछन्: Squid ले अपस्ट्रिमबाट नयाँ नलिई जवाफ पठाउन सक्छ। धेरै अपलोड हुने कामले अर्को कुरा देखाउँछ: जवाफ मात्र गन्दा अनुरोधको दिशा बजेटबाहिर रहन्छ।

CONNECT का लागि, प्रोक्सीले सुरुङभित्रको प्रत्येक इन्क्रिप्टेड फाइल वा पृष्ठ नबुझी पठाइएको ट्राफिक हिसाब गर्न सक्छ। तर सुरुङको बाइट जम्मालाई डाउनलोड गरिएका अनुप्रयोग वस्तुहरूको सटीक सूचीमा बदल्न सक्दैन।

कोटा सम्झौता काउन्टरको छेउमा लेख्नुहोस्: दिशा, अवलोकन बिन्दु, लेखा अवधि र पहिचान। त्यसपछि लग ढाँचाको संस्करण प्रतिवेदनसँगै राख्नुहोस्। बाइटको अर्थबारे मतभेद प्रत्येक मानलाई अनुमानित सुधार गुणकले गुणन गरेर «सुधार्नु» हुँदैन। प्रवर्तनका लागि सम्पन्न कारोबारको जम्मा प्रत्यक्ष प्रयोगभन्दा पछि पर्न सक्छ।

सम्बन्धित लेखहरू