Terdapat pilihan Squid bernama retry_on_error, tetapi namanya lebih luas daripada tafsiran bergunanya. Ia tidak bermakna setiap permintaan yang gagal akan diulang tanpa henti sehingga halaman berfungsi.

Dalam keluaran yang menyokong direktif ini, ia dimatikan secara lalai. Senarai ulangan yang didokumenkan ialah 403, 500, 501, 502, 503 dan 504, dan permintaan dicuba melalui destinasi lain yang berfungsi. Ini amat relevan dalam hierarki dengan laluan penghantaran alternatif. Ia bukan sekadar percubaan semula bermasa bagi soket yang sama ke pelayan yang sama.

Namakan kegagalan terlebih dahulu

Penolakan semasa menyambung ke proksi, kegagalan pengesahan proksi, ralat HTTP daripada asal dan respons yang terputus selepas penghantaran bermula tidak menawarkan peluang ulangan yang sama. Jangan jangkakan satu tetapan mengendalikan keempat-empatnya dengan sama.

Untuk keluar peribadi, tentukan juga sama ada laluan alternatif boleh diterima. Induk lain mungkin mempunyai alamat sumber awam, dasar pengesahan atau lokasi rangkaian yang berbeza. Kejayaan melalui alternatif itu mungkin melanggar sebab induk pertama dipilih.

Operasi aplikasi membawa kebimbangan lain: mengulang permintaan boleh mengulang kesannya. Klien dan pelayan memerlukan semantik ulangan yang sesuai, terutamanya untuk operasi yang mencipta atau menukar data. Tetapan proksi bukan pengganti pengendalian hasil tidak pasti di peringkat aplikasi.

Baca direktif untuk keluaran tepat anda; rujukan menyenaraikan ketersediaan dan tingkah laku lalai. Perhatikan juga tarikh akhir permintaan dan jumlah tunggu yang kelihatan kepada pengguna. Percubaan penghantaran tambahan boleh menghabiskan masa yang tinggal tanpa menghasilkan hasil yang lebih baik.

Apabila menyiasat kegagalan berselang-seli, rekod status, induk atau destinasi yang dipilih dan urutan percubaan. Jika tidak, ulangan boleh membuat masalah penghalaan berulang kelihatan seperti laman web yang lambat secara umum sambil menyembunyikan laluan yang sebenarnya gagal.

Artikel berkaitan