Squid retry_on_error: stavové kódy a alternativní trasy
Používejte Squid retry_on_error v jeho dokumentovaném rozsahu stavů a alternativních cílů, místo abyste jej považovali za univerzální nastavení opakování požadavků.
V Squidu existuje volba retry_on_error, ale její název je širší než její užitečný výklad. Neznamená, že se každý neúspěšný požadavek bude opakovat neomezeně, dokud stránka nezačne fungovat.
Ve verzích, které tuto direktivu podporují, je ve výchozím stavu vypnutá. Dokumentovaný seznam opakování je 403, 500, 501, 502, 503 a 504 a požadavek zkouší přes jiný funkční cíl. To je zvláště důležité v hierarchii s alternativními cestami předávání. Nejde jen o časově omezené opakování stejného socketu na stejný server.
Nejprve pojmenujte selhání
Odmítnutí při připojování k proxy, selhání autentizace proxy, chyba HTTP od zdroje a odpověď přerušená po zahájení doručování nepředstavují stejnou příležitost k opakování. Neočekávejte, že jedno nastavení bude všechny čtyři případy řešit stejně.
U privátního výstupu také rozhodněte, zda je alternativní cesta přijatelná. Jiný rodič může mít jinou veřejnou zdrojovou adresu, zásady autentizace nebo umístění v síti. Úspěch přes tuto alternativu může narušit důvod, proč byl první rodič vybrán.
Operace aplikace přinášejí další problém: opakování požadavku může opakovat jeho účinek. Klient a server potřebují vhodnou sémantiku opakování, zejména u operací, které vytvářejí nebo mění data. Nastavení proxy nenahrazuje zpracování nejistých výsledků na úrovni aplikace.
Přečtěte si direktivu pro vaše přesné vydání; reference uvádí dostupnost a výchozí chování. Mějte na paměti také termíny požadavků a celkovou dobu čekání viditelnou uživateli. Další pokus o předání může spotřebovat zbývající čas, aniž by přinesl lepší výsledek.
Při vyšetřování občasných selhání zaznamenejte stav, zvoleného rodiče nebo cíl a pořadí pokusů. Jinak mohou opakování způsobit, že se opakující problém se směrováním jeví jako obecně pomalý web, a přitom skryjí cestu, která skutečně selhala.