每一個來自客戶端請求在varnish中都是一個session，一個session會被分配到一個空閒的thread處理。 當沒有空閒的thread時，varnish會創建新的thread來處理。 當全局的thread數量超過thread_pool_max * thread_pools時， varnish會將請求放入隊列，當隊列滿時，varnish開始丟棄請求。 Varnish的默認配置，thread_pools爲2，thread_pool_max爲500，也即最多1000個thread。 當併發處理的請求量（注意不等價與併發請求量）大於1000時，varnish就過載了。
下面我們來看看如何調整線程池
管理命令：
Varnishadm
param.show -l //列出所有配置參數，與註釋。
Param.show
thread_pool_max 1000 [threads] //定義線程池最大線程
thread_pool_min 50 [threads] //每個線程池最小活動線程
thread_pools 2 [pools] //啓用多少個線程池
lru_interval 2 [seconds] //使用（LRU）最近最少使用算法，清理緩存對象的頻率，默認2秒一次。
listen_depth 1024 [connections] //當線程池滿了，後續請求隊列的長度。
現在我們對這些參數進行調整
param.set thread_pool_max 2000
param.set thread_pools 4
param.set thread_pool_min 100
調整完成查看一下
注意：thread_pools 參考機器物理核心的數量，官方建議設置爲2。線程數不建議太多，超過5000也許會帶來服務不穩定。
配置調優
beresp.grace 表示一個object即使已經過期了，仍然在緩存中存放一段時間。
req.grace 表示，當一個請求命中了一個剛過期的object，由於回源需要一段時間， 爲了立刻返回，那麼在過期後的req.grace時間內， 可以將過期的那個object返回給客戶端， 當然，這要求beresp.grace >= req.grace
Example：
與Cookie有關的緩存
業務要求大致如此，對於一個domain下的請求，客戶端總是會帶Cookie， 而該domain下面有一些請求是需要緩存的。在之前的配置中，vcl_recv中設置了只要有Cookie就return(pass)， 因此如果某個url需要緩存，就需要手動對該url在vcl_recv中 刪除req.http.Cookie，並在vcl_fetch中刪除beresp.http.Set-Cookie。 這樣運維的工作與後端的開發工作就耦合了。期望的效果是，後端如果需要緩存某個url，則在該請求的返回頭中帶有Cache-Control頭， 然後Varnish就自動根據該頭來緩存相應的時間，而如果一個請求的返回中沒有Cache-Control頭，則默認不能緩存。
varnishstat 用於查看varnish狀態
日誌功能的使用
Service varnishlog start
查看日誌
varnishlog
本章內容並非全部原創，有引用大牛網友的分享。
推薦閱讀：http://blog.csdn.net/keda8997110/article/details/8777153