Squid retry_on_error: ລະຫັດສະຖານະ ແລະ ເສັ້ນທາງອື່ນ

ມີຕົວເລືອກໃນ Squid ທີ່ຊື່ retry_on_error ແຕ່ຊື່ນັ້ນກວ້າງກວ່າການຕີຄວາມໝາຍທີ່ເປັນປະໂຫຍດຂອງມັນ. ມັນບໍ່ໄດ້ໝາຍຄວາມວ່າທຸກຄຳຮ້ອງຂໍທີ່ລົ້ມເຫຼວຈະຖືກເຮັດຊ້ຳຢ່າງບໍ່ມີຂີດຈຳກັດຈົນກວ່າໜ້າເວັບຈະເຮັດວຽກໄດ້.

ໃນສະບັບທີ່ຮອງຮັບຄຳສັ່ງນີ້ ມັນຖືກປິດເປັນຄ່າເລີ່ມຕົ້ນ. ລາຍການສົ່ງຄືນທີ່ເອກະສານໄວ້ແມ່ນ 403, 500, 501, 502, 503 ແລະ 504 ແລະ ມັນລອງຄຳຮ້ອງຂໍຜ່ານຈຸດໝາຍອື່ນທີ່ເຮັດວຽກໄດ້. ສິ່ງນີ້ສຳຄັນໂດຍສະເພາະໃນລະບົບຊັ້ນທີ່ມີເສັ້ນທາງສົ່ງຕໍ່ອື່ນ. ມັນບໍ່ແມ່ນພຽງການລອງຄືນຕາມເວລາຂອງຊັອກເກັດດຽວກັນໄປຫາເຊີບເວີດຽວກັນ.

ຕັ້ງຊື່ຄວາມລົ້ມເຫຼວກ່ອນ

ການປະຕິເສດຂະນະເຊື່ອມຕໍ່ກັບພຣັອກຊີ, ການລົ້ມເຫຼວຂອງການກວດສອບພຣັອກຊີ, ຂໍ້ຜິດພາດ HTTP ຈາກຕົ້ນກຳເນີດ ແລະ ການຕອບສະໜອງທີ່ຖືກຕັດຫຼັງຈາກເລີ່ມສົ່ງ ບໍ່ໄດ້ໃຫ້ໂອກາດສົ່ງຄືນຄືກັນ. ຢ່າຄາດຫວັງວ່າການຕັ້ງຄ່າດຽວຈະຈັດການທັງສີ່ຢ່າງຄືກັນ.

ສຳລັບທາງອອກສ່ວນຕົວ ຕ້ອງຕັດສິນວ່າເສັ້ນທາງອື່ນຍອມຮັບໄດ້ຫຼືບໍ່. ພໍ່ແມ່ອື່ນອາດມີທີ່ຢູ່ແຫຼ່ງສາທາລະນະ, ນະໂຍບາຍການກວດສອບ ຫຼື ຕຳແໜ່ງເຄືອຂ່າຍອື່ນ. ຄວາມສຳເລັດຜ່ານທາງເລືອກນັ້ນອາດລະເມີດເຫດຜົນທີ່ພໍ່ແມ່ທຳອິດຖືກເລືອກ.

ການດຳເນີນງານຂອງແອັບພລິເຄຊັນນຳຄວາມກັງວົນອີກຢ່າງມາ: ການເຮັດຄຳຮ້ອງຂໍຊ້ຳອາດເຮັດຜົນກະທົບຂອງມັນຊ້ຳ. ລູກຄ້າ ແລະ ເຊີບເວີຕ້ອງການຄວາມໝາຍການສົ່ງຄືນທີ່ເໝາະສົມ ໂດຍສະເພາະສຳລັບການດຳເນີນງານທີ່ສ້າງ ຫຼື ປ່ຽນຂໍ້ມູນ. ການຕັ້ງຄ່າພຣັອກຊີບໍ່ແມ່ນການທົດແທນການຈັດການຜົນລັບທີ່ບໍ່ແນ່ນອນໃນລະດັບແອັບພລິເຄຊັນ.

ອ່ານຄຳສັ່ງສຳລັບສະບັບທີ່ແນ່ນອນຂອງທ່ານ; ເອກະສານອ້າງອີງລາຍງານຄວາມພ້ອມໃຊ້ ແລະ ພຶດຕິກຳເລີ່ມຕົ້ນ. ຮັກສາ ກຳນົດເວລາຄຳຮ້ອງຂໍ ແລະ ການລໍຖ້າທັງໝົດທີ່ຜູ້ໃຊ້ເຫັນ ໄວ້ໃນໃຈດ້ວຍ. ການລອງສົ່ງຕໍ່ເພີ່ມເຕີມອາດໃຊ້ເວລາທີ່ເຫຼືອໂດຍບໍ່ໄດ້ຜົນທີ່ດີກວ່າ.

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