Squid ఎప్పుడు APT ప్యాకేజీలను క్యాష్ చేయగలదు
ప్యాకేజీ అభ్యర్థనలు Squid హిట్లు అవుతాయని ఆశించే ముందు HTTP రవాణా, క్యాష్ నిల్వ, ఆబ్జెక్ట్ పరిమాణం మరియు APT యొక్క cache-control సెట్టింగ్లను తనిఖీ చేయండి.
APT మరియు aptitude HTTP ద్వారా రిపాజిటరీ ఫైళ్లను పొందగలవు. Squid అర్హత ఉన్న HTTP ప్రతిస్పందనను క్యాష్ చేయగలదు; క్లయింట్ వెబ్ బ్రౌజర్ కావాల్సిన అవసరం లేదు.
Squid 6 లేదా 7 అమరికలో, ప్రతి ప్యాకేజీ బదిలీ ఇంకా మూలాన్ని చేరుకుంటున్నప్పుడు ఈ ఇన్పుట్లను తనిఖీ చేయండి:
- డౌన్లోడ్ HTTPని ఉపయోగిస్తుంది, లేదా Squid ఇతర మార్గంలో HTTP మార్పిడికి ప్రాప్యత కలిగి ఉంటుంది. HTTPS CONNECT సొరంగం మాత్రమే ప్యాకేజీ ప్రతిస్పందనను క్యాష్ కోసం బహిర్గతం చేయదు.
- క్యాష్లో సరైన నిల్వ కాన్ఫిగర్ చేయబడింది. విజయవంతమైన ఫార్వర్డింగ్ డిస్క్ క్యాష్ ఉన్నట్లు రుజువు చేయదు.
- ఆర్కైవ్ వర్తించే క్యాష్ డైరెక్టరీ గరిష్ఠ ఆబ్జెక్ట్ పరిమాణంలో సరిపోతుంది. చిన్న మెటాడేటా మరియు పెద్ద .deb వేర్వేరు ఫలితాలను ఇవ్వగలవు.
- అభ్యర్థన మరియు ప్రతిస్పందన తమ cache-control విధానం ప్రకారం నిల్వ మరియు పునర్వినియోగాన్ని అనుమతిస్తాయి.
APT Acquire::http::No-Cache, Max-Age మరియు No-Store అందిస్తుంది. No-Store అభ్యర్థించిన ఆర్కైవ్ ఫైళ్లు నిల్వ చేయబడకుండా నిరోధించగలదు. No-Cache నిల్వ చేసిన ప్రతిస్పందనను పునర్వినియోగించే ముందు పునఃధృవీకరణను అడుగుతుంది. ప్రభావవంతమైన APT కాన్ఫిగరేషన్ మరియు Squid విధానాన్ని తనిఖీ చేయండి.
అదే పూర్తి URLను పోల్చి access.logలో క్యాష్ ఫలితాన్ని తనిఖీ చేయండి. వేర్వేరు మిర్రర్ హోస్ట్లు, మారిన రిపాజిటరీ మార్గాలు లేదా స్థానికంగా క్యాష్ చేసిన ప్యాకేజీ రెండు ఇన్స్టాల్లు ఎప్పుడూ ఒకే నెట్వర్క్ ఆబ్జెక్ట్ను అభ్యర్థించవు అని అర్థం కావచ్చు.
రిపాజిటరీ మిర్రర్ డిమాండ్ ఆధారిత HTTP క్యాష్ పునర్వినియోగంపై మాత్రమే ఆధారపడకుండా రిపాజిటరీ కంటెంట్ను ఉద్దేశపూర్వకంగా నిర్వహిస్తుంది.