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 കാഷെ പുനരുപയോഗത്തെ മാത്രം ആശ്രയിക്കാതെ റിപ്പോസിറ്ററി ഉള്ളടക്കം ബോധപൂർവ്വം പരിപാലിക്കുന്നു.