Squid က APT ပက်ကေ့ချ်များကို ဘယ်အချိန်တွင် cache လုပ်နိုင်သည်

ပက်ကေ့ချ် တောင်းဆိုမှုများ Squid hit ဖြစ်လာမည်ဟု မမျှော်လင့်မီ HTTP သယ်ယူမှု၊ cache သိုလှောင်မှု၊ အရာဝတ္ထု အရွယ်အစားနှင့် APT ၏ cache-control ဆက်တင်များကို စစ်ဆေးပါ။

APT နှင့် aptitude သည် HTTP မှတစ်ဆင့် repository ဖိုင်များကို ရယူနိုင်သည်။ Squid သည် အရည်အချင်းပြည့်သော HTTP တုံ့ပြန်မှုကို cache လုပ်နိုင်သည်။ client သည် ဝဘ်ဘရောက်ဇာ ဖြစ်ရန် မလိုအပ်ပါ။

Squid 6 သို့မဟုတ် 7 တပ်ဆင်မှုတွင် ပက်ကေ့ချ် ပို့ဆောင်မှုတိုင်း မူလအရင်းအမြစ်သို့ ရောက်နေသေးပါက ဤထည့်သွင်းချက်များကို စစ်ဆေးပါ။

  • ဒေါင်းလုဒ်သည် HTTP ကို အသုံးပြုသည်၊ သို့မဟုတ် Squid သည် HTTP ဖလှယ်မှုကို အခြားနည်းဖြင့် ရောက်ရှိနိုင်သည်။ HTTPS CONNECT ဥမင်တစ်ခုတည်းဖြင့် ပက်ကေ့ချ် တုံ့ပြန်မှုကို cache အတွက် မဖော်ထုတ်ပါ။
  • Cache တွင် သင့်လျော်သော သိုလှောင်မှု သတ်မှတ်ထားသည်။ အောင်မြင်စွာ ပို့ဆောင်နိုင်ခြင်းသည် disk cache ရှိကြောင်း သက်သေမပြပါ။
  • Archive သည် သက်ဆိုင်ရာ cache directory ၏ အများဆုံး အရာဝတ္ထု အရွယ်အစားထဲ ဝင်သည်။ metadata ငယ်ငယ်နှင့် .deb ကြီးကြီးသည် မတူညီသော ရလဒ်များ ဖြစ်နိုင်သည်။
  • တောင်းဆိုမှုနှင့် တုံ့ပြန်မှုသည် ၎င်းတို့၏ cache-control မူဝါဒအရ သိုလှောင်ခြင်းနှင့် ပြန်လည်အသုံးပြုခြင်းကို ခွင့်ပြုသည်။

APT သည် Acquire::http::No-Cache၊ Max-Age နှင့် No-Store ကို ဖော်ပြသည်။ No-Store သည် တောင်းဆိုထားသော archive ဖိုင်များကို မသိုလှောင်နိုင်အောင် တားဆီးနိုင်သည်။ No-Cache သည် သိုလှောင်ထားသော တုံ့ပြန်မှုကို ပြန်မသုံးမီ ပြန်လည်အတည်ပြုရန် တောင်းဆိုသည်။ ထိရောက်သော APT ဖွဲ့စည်းမှုနှင့် Squid ၏ မူဝါဒကို စစ်ဆေးပါ။

တူညီသော URL အပြည့်အစုံကို နှိုင်းယှဉ်ပြီး access.log တွင် cache ရလဒ်ကို စစ်ဆေးပါ။ မတူညီသော mirror host များ၊ ပြောင်းလဲထားသော repository လမ်းကြောင်းများ သို့မဟုတ် locally cache လုပ်ထားသော ပက်ကေ့ချ်သည် တပ်ဆင်မှုနှစ်ခု ဘယ်တော့မှ တူညီသော ကွန်ရက်အရာဝတ္ထုကို မတောင်းဆိုကြောင်း ဆိုလိုနိုင်သည်။

Repository mirror သည် ဝယ်လိုအားအခြေပြု HTTP cache ပြန်လည်အသုံးပြုမှုကို သာ မှီခိုမည့်အစား repository အကြောင်းအရာကို တမင်တကာ ထိန်းသိမ်းထားသည်။

ဆက်စပ်ဆောင်းပါးများ