ເມື່ອໃດ Squid ສາມາດ cache ຊອງ APT

ກວດສອບການສົ່ງ HTTP, ບ່ອນເກັບ cache, ຂະໜາດວັດຖຸ ແລະ ການຕັ້ງຄ່າ cache-control ຂອງ APT ກ່ອນຈະຄາດວ່າຄຳຮ້ອງຊອງຈະກາຍເປັນ Squid hits.

APT ແລະ aptitude ສາມາດດຶງໄຟລ໌ຄັງຜ່ານ HTTP. Squid ສາມາດ cache ການຕອບສະໜອງ HTTP ທີ່ເໝາະສົມ; ລູກຄ້າບໍ່ຈຳເປັນຕ້ອງເປັນໂປຣແກຣມທ່ອງເວັບ.

ໃນການຕິດຕັ້ງ Squid 6 ຫຼື 7, ກວດສອບອິນພຸດເຫຼົ່ານີ້ ເມື່ອການສົ່ງຊອງແຕ່ລະຄັ້ງຍັງໄປຮອດຕົ້ນກຳເນີດ:

  • ການດາວໂຫຼດໃຊ້ HTTP, ຫຼື Squid ມີການເຂົ້າເຖິງການແລກປ່ຽນ HTTP ໃນທາງອື່ນ. ອຸໂມງ HTTPS CONNECT ຢ່າງດຽວບໍ່ເປີດເຜີຍການຕອບສະໜອງຊອງສຳລັບ cache.
  • Cache ມີບ່ອນເກັບທີ່ເໝາະສົມຕັ້ງຄ່າໄວ້. ການສົ່ງຕໍ່ທີ່ສຳເລັດບໍ່ໄດ້ພິສູດວ່າມີ cache ດິສກ໌.
  • ຄັງເກັບພໍດີກັບຂະໜາດວັດຖຸສູງສຸດຂອງສາລະບານ cache ທີ່ໃຊ້. metadata ນ້ອຍ ແລະ .deb ໃຫຍ່ອາດໃຫ້ຜົນຕ່າງກັນ.
  • ຄຳຮ້ອງ ແລະ ການຕອບສະໜອງອະນຸຍາດການເກັບ ແລະ ການນຳກັບມາໃຊ້ຕາມນະໂຍບາຍ cache-control ຂອງມັນ.

APT ສະເໜີ Acquire::http::No-Cache, Max-Age ແລະ No-Store. No-Store ສາມາດປ້ອງກັນບໍ່ໃຫ້ເກັບໄຟລ໌ຄັງທີ່ຮ້ອງຂໍ. No-Cache ຂໍການກວດສອບຄືນກ່ອນນຳການຕອບສະໜອງທີ່ເກັບໄວ້ມາໃຊ້. ກວດສອບການຕັ້ງຄ່າ APT ທີ່ມີຜົນ ແລະ ນະໂຍບາຍຂອງ Squid.

ປຽບທຽບ URL ເຕັມອັນດຽວກັນ ແລະ ກວດສອບຜົນ cache ໃນ access.log. ໂຮສກະຈົກຕ່າງກັນ, ເສັ້ນທາງຄັງທີ່ປ່ຽນແປງ ຫຼື ຊອງທີ່ cache ໄວ້ໃນເຄື່ອງອາດໝາຍຄວາມວ່າການຕິດຕັ້ງສອງອັນບໍ່ເຄີຍຮ້ອງຂໍວັດຖຸເຄືອຂ່າຍອັນດຽວກັນ.

ກະຈົກຄັງຮັກສາເນື້ອໃນຄັງຢ່າງເຈດຕະນາ ແທນທີ່ຈະອາໄສພຽງແຕ່ການນຳ cache HTTP ມາໃຊ້ຕາມຄວາມຕ້ອງການ.

ບົດຄວາມທີ່ກ່ຽວຂ້ອງ