Squid retry_on_error: коды стану і альтэрнатыўныя маршруты
Выкарыстоўвайце Squid retry_on_error у межах яго дакументаванага ахопу станаў і альтэрнатыўных прызначэнняў, а не як універсальную наладу паўтору запытаў.
У Squid ёсць опцыя retry_on_error, але яе назва шырэйшая за карыснае тлумачэнне. Яна не азначае, што кожны няўдалы запыт будзе паўтарацца бясконца, пакуль старонка не запрацуе.
У выпусках, якія падтрымліваюць гэту дырэктыву, яна па змаўчанні выключана. Дакументаваны спіс паўтораў — 403, 500, 501, 502, 503 і 504, і запыт спрабуецца праз іншае працоўнае прызначэнне. Гэта асабліва важна ў іерархіі з альтэрнатыўнымі шляхамі перасылкі. Гэта не проста паўтор з тайм-аўтам таго ж сокета да таго ж сервера.
Спачатку назавіце збой
Адмова падчас злучэння з проксі, збой аўтэнтыфікацыі проксі, памылка HTTP ад крыніцы і адказ, абрэзаны пасля пачатку перадачы, не даюць аднолькавай магчымасці паўтору. Не чакайце, што адна налада абыйдзецца з усімі чатырма аднолькава.
Для прыватнага выхаду таксама вырашыце, ці прымальны альтэрнатыўны шлях. Іншы бацькоўскі сервер можа мець іншы публічны адрас крыніцы, палітыку аўтэнтыфікацыі або месца ў сетцы. Поспех праз гэту альтэрнатыву можа парушыць прычыну выбару першага бацькі.
Аперацыі праграмы дадаюць яшчэ адну праблему: паўтор запыту можа паўтарыць яго эфект. Кліенту і серверу патрэбна належная семантыка паўтору, асабліва для аперацый, якія ствараюць або змяняюць даныя. Налада проксі не замяняе апрацоўку няпэўных вынікаў на ўзроўні праграмы.
Чытайце дырэктыву для вашага дакладнага выпуску; даведнік пералічвае даступнасць і паводзіны па змаўчанні. Трымайце ў полі зроку таксама тэрміны запытаў і агульны час чакання карыстальніка. Дадатковая спроба перасылкі можа спажыць рэшту часу, не даўшы лепшага выніку.
Разследуючы перамежныя збоі, запісвайце стан, выбранага бацьку або прызначэнне і паслядоўнасць спроб. Інакш паўторы могуць зрабіць пастаянную праблему маршрутызацыі падобнай да проста павольнага сайта, хаваючы шлях, які насамрэч збаіў.