varnish与squid的比较

son30

　　生产环境中尝试使用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
　　* soft memlock 1048576
　　或执行 ulimit -HSl 1048576
　　默认的memlock 只有32K，对varnish来说，太小太小。varnish使用内存块保存日志，故这个值需要调大一些。
　　上面的值将其调整为1G，即可解决varnish流量高于squid的问题
　　4. varnish运行中频繁出现503错误，400错误
　　出现503错误这是因为varnish对后端服务器响应header有限制，默认长度是2048，可将其调大一些
　　-p http_resp_hdr_len=8192
　　再重启即可解决503错误。
　　出现400错误是因为varnish认为客户端请求header行数及长度过大，其默认最大接受的请求header行数为64，最大长度（所有请求header行长度之和）为2048，解决这个问题比较简单，在varnish启动参数中加入：
　　-p http_max_hdr=256
　　-p http_req_hdr_len=8192
　　再重启varnish, 即可解决其400错误。