ເມື່ອໃດທີ່ cache ຂອງ proxy ຮ່ວມຊ່ວຍ crawler
ປະເມີນຊັບພະຍາກອນທີ່ເກີດຊ້ຳ, ຄວາມສົດໃໝ່ ແລະ ຄຳຮ້ອງຂໍຕົວຈິງຂອງ crawler ກ່ອນຈະຄາດຫວັງວ່າ forward-proxy cache ຮ່ວມຈະເພີ່ມປະສິດທິພາບ.
ສົມມຸດວ່າຜູ້ປະຕິບັດງານຫຼາຍຄົນໃນ browser ເປີດໜ້າຕ່າງໆ ຂອງເວັບໄຊດຽວ. ໜ້າເຫຼົ່ານັ້ນອ້າງອີງ stylesheet, logo ແລະ script bundle ດຽວກັນ. Forward cache ຮ່ວມສາມາດເຮັດໃຫ້ການດຶງຄັ້ງທຳອິດມີປະໂຫຍດຕໍ່ຜູ້ປະຕິບັດງານຕໍ່ໄປ ເມື່ອຄຳຕອບສາມາດໃຊ້ຊ້ຳໄດ້.
ຕອນນີ້ປ່ຽນພາລະວຽກ: ຜູ້ປະຕິບັດງານແຕ່ລະຄົນດາວໂຫຼດເອກະສານ HTML ພຽງໜຶ່ງ ແລະ ບໍ່ເຄີຍໂຫຼດຊັບພະຍາກອນທີ່ເຊື່ອມຕໍ່. stylesheet ຮ່ວມຍັງຢູ່ໃນ markup, ແຕ່ບໍ່ມີຜູ້ປະຕິບັດງານໃດຮ້ອງຂໍມັນ. ມັນບໍ່ເພີ່ມຫຍັງໃຫ້ອັດຕາການຕີ cache ຂອງ proxy.
ເລີ່ມຈາກຄຳຮ້ອງຂໍທີ່ crawler ຂອງທ່ານເຮັດຕົວຈິງ
Browser ທີ່ສະແດງໜ້າ ແລະ HTTP client ທີ່ເອົາແຫຼ່ງຂໍ້ມູນຂອງມັນ ສ້າງຊຸດຄຳຮ້ອງຂໍທີ່ແຕກຕ່າງກັນ. ກວດເບິ່ງຊຸດເຫຼົ່ານັ້ນກ່ອນເລືອກການອອກແບບ cache.
| ພາລະວຽກ | ຄວາມເປັນໄປໄດ້ຂອງການໃຊ້ຊ້ຳຮ່ວມ |
|---|---|
| ຜູ້ປະຕິບັດງານດຶງຊັບພະຍາກອນສາທາລະນະດຽວກັນຊ້ຳໆ | ມີປະໂຫຍດເມື່ອກົດຄວາມສົດໃໝ່ ແລະ ກະແຈ cache ອະນຸຍາດ |
| ທຸກຄຳຮ້ອງຂໍມີ URL ຫຼື ຮູບແບບຄຳຕອບສະເພາະ | ການທັບຊ້ອນທີ່ໃຊ້ຊ້ຳໄດ້ມີໜ້ອຍ |
| ຄຳຕອບຕ້ອງກວດສອບຄືນກ່ອນໃຊ້ຊ້ຳ | ອາດປະຢັດໄບຕ໌ຄຳຕອບ ແຕ່ຍັງຕ້ອງເດີນທາງໄປທາງເທິງ |
| ຜູ້ປະຕິບັດງານຕອບຄຳຮ້ອງຂໍຈາກ cache ທ້ອງຖິ່ນຂອງຕົນແລ້ວ | ຄຳຮ້ອງຂໍເຫຼົ່ານັ້ນອາດບໍ່ເຄີຍຮອດ proxy ຮ່ວມ |
ຄວາມເທົ່າກັນຂອງ URL ຢ່າງດຽວບໍ່ພຽງພໍ. ນະໂຍບາຍຄວາມສົດໃໝ່ຂອງຄຳຕອບ ແລະ ຊ່ອງຂໍ້ມູນທີ່ Vary ຕັ້ງຊື່ສາມາດແຍກຕົວແທນ. ເນື້ອຫາສ່ວນຕົວ, ທີ່ເກັບບໍ່ໄດ້ ຫຼື ທີ່ຢືນຢັນແລ້ວ ຕ້ອງການກົດ cache ຮ່ວມທີ່ໃຊ້ໄດ້; ບໍ່ຄວນບັງຄັບມັນໃຫ້ເປັນຜົນສາທາລະນະດຽວ ພຽງເພື່ອເພີ່ມຈຳນວນການຕີ.
ສຳລັບການສັນຈອນ HTTPS CONNECT ປົກກະຕິ, forward proxy ຂົນອຸໂມງທີ່ເຂົ້າລະຫັດ ແລະ ບໍ່ມີວັດຖຸ HTTP ທາງໃນໃຫ້ cache. ການຕິດຕັ້ງທີ່ມີການກວດ TLS ມີພຶດຕິກຳຄວາມໄວ້ໃຈ ແລະ ການປະມວນຜົນຕ່າງກັນ. ລວມໂໝດຕົວຈິງເມື່ອປະເມີນວ່າ cache ວັດຖຸມີ ຫຼື ບໍ່.
ການຕີ cache ສາມາດຫຼີກລ້ຽງການດຶງຈາກທາງເທິງ ໃນຂະນະທີ່ການພາດຍັງຈ່າຍຄ່າວຽກຂອງຕົວກາງ. ປຽບທຽບໄບຕ໌ທີ່ເປັນປະໂຫຍດທີ່ສຳເລັດ, ການສັນຈອນໄປທາງເທິງ ແລະ ຄວາມລ່າຊ້າ ສຳລັບພາລະວຽກທີ່ຕັ້ງໃຈໄວ້. ຈຳນວນ thread ອະທິບາຍຄວາມພ້ອມກັນ; ມັນບໍ່ໄດ້ອະທິບາຍວ່າ thread ເຫຼົ່ານັ້ນແບ່ງປັນເນື້ອຫາທີ່ໃຊ້ຊ້ຳໄດ້ເທົ່າໃດ.