0
我無法理解在後端500錯誤情況下Varnish的行爲。 - 爲什麼它會增加MAIN.n_object計數器?我認爲它應該只緩存20x和重定向。 - 如果第一個請求使用來自後端的500響應完成,則對相同url不進行緩存的所有後續請求,即使後端開始返回200響應。 幫我理解這個邏輯。爲什麼Varnish在500錯誤後停止緩存200響應
我無法理解在後端500錯誤情況下Varnish的行爲。 - 爲什麼它會增加MAIN.n_object計數器?我認爲它應該只緩存20x和重定向。 - 如果第一個請求使用來自後端的500響應完成,則對相同url不進行緩存的所有後續請求,即使後端開始返回200響應。 幫我理解這個邏輯。爲什麼Varnish在500錯誤後停止緩存200響應
如果你真的使用默認的VCL,那麼默認的邏輯就像你描述的那樣。但是你錯過了它在一段時間後開始緩存它。通常2分鐘。
這需要實現hit-for-pass - 我對此的理解是:光油會默認堆積requets到後端,而不是給他們,他們到達了優化。當Varnish看到某些東西不可緩存(500狀態等)時,它不會執行堆積行爲並直接與後端對話(即時通過)。
如果您想要減少頁面被標記爲按轉換時間的時間量,則需要添加一些VCL。這將確保沒有運行內置的具有120s值的VCL。以下將以500秒狀態標記爲不可緩存10秒的頁面:
sub vcl_backend_response {
if (beresp.status == 500) {
set beresp.ttl = 10s;
set beresp.uncacheable = true;
return (deliver);
}
}
你是100%正確的!最近我用計時器測量了它的2分鐘問題期。如果剛剛發生500錯誤,後端再次正常,爲什麼在這2米通過之前無法緩存它的響應? – Molfar
如果在500次錯誤後的10秒內後端沒問題,如何避免在110秒內一次又一次地取回? – Molfar
查看更新的答案。類似的東西應該工作(未經測試的代碼)。 –