varnish與squid的比較

生產環境中嘗試使用varnish替代squid的主要原因：

1. squid不支援多核cpu, 生產環境中大多使用dell r610系列，這種型別機器配置為2個4核雙線程cpu, 作業系統識別為16個，對squid來說，只能利用到乙個邏輯cpu, 其它15個邏輯cpu相當於一直浪費。

2. squid無法批量清除快取

3. squid3.0目前還無法支援http 1.1, 這對一些管理調整（如gzip壓縮，cache-control）帶來不必要的麻煩

4. 目前我還未找到squid的grace模式（指源站不可到達時，繼續使用過期快取為使用者提供服務），而varnish是完全支援的。

5. 經過生產環境數個月反覆測試，同樣訪問量情況下，varnish消耗的更少，也沒有出現過崩潰情況，而squid因為不支援多核，導致dell r610機器負載往往超過4，但使用varnish後，機器負載從來沒超過1.5

經過反覆測試，我們已經開始在日獨立ip百萬級站點中使用varnish替換squid了。

但這個過程中，充滿太多未知情況，目前我們所遇到的關鍵問題下：

1. 高流量情況下iptables丟包

ip_conntrack: table full, dropping packet.

按網上常規方法，只修改/etc/sysctl.conf是無效的

需要以下兩步，方可解決：

/boot/grub/grub.conf kernel行中增加引數

ip_conntrack.hashsize=524288

/etc/sysctl.conf中增加

net.ipv4.netfilter.ip_conntrack_max = 2097152

注意，上面的操作需要重啟機器

2. 登入shell ulimit的預設值

/etc/security/limits.conf中加入

* soft nofile 655360

* hard nofile 655360

預設的檔案描述符限制為1024, 太小，即使調整成65536，對高負載機器也可能不夠，故設定為655360,但也要注意，這個值不能設定過大，否則會導致shell無法登入。

修改/etc/security/limits.conf後，只對登入shell有效。對開機執行的程式，一定要注意這個問題（在啟動前設定ulimit）

shell級的資源限制來自於/etc/security/limits.conf，那麼系統級的資源限制可在**修改？

3. squid換為varnish後流量增加的解決方案：

/etc/security/limits.conf中加入

* soft memlock 1048576

或執行 ulimit -hsl 1048576

預設的memlock 只有32k，對varnish來說，太小太小。varnish使用記憶體塊儲存日誌，故這個值需要調大一些。

上面的值將其調整為1g，即可解決varnish流量高於squid的問題

4. varnish執行中頻繁出現503錯誤，400錯誤

出現503錯誤這是因為varnish對後端伺服器響應header有限制，預設長度是2048，可將其調大一些

再重啟即可解決503錯誤。

出現400錯誤是因為varnish認為客戶端請求header行數及長度過大，其預設最大接受的請求header行數為64，最大長度（所有請求header行長度之和）為2048，解決這個問題比較簡單，在varnish啟動引數中加入：

再重啟varnish, 即可解決其400錯誤。