（再不写 blog 就要荒到长出草来了。。）

squid 2.6 出来有那么一段时候了，一直没有时间试验。最近终于找到了一些时间，于是决定将某站的 squid 升级上去玩玩。

2.6 的 RPM 只有 fedora development 里面才有(我是非常懒的，RPM 基本都是拿现成的来用)，好在依赖关系不是非常复杂，简单修改了一下去掉了一些依赖比较多的认证模块比如 ntlm 和 ldap 之类，FC6 的 RPM 就在 FC3 上面 build 出来了。

RPM 有了，但是暂时还不能升级，因为squid 之王说过配置文件格式变化了，原来给懒人使用的 http_accel 系列都去掉了，统一进了 cache_peer 里面，这个本来是很好的想法，但是 cache_peer 这语法有个局限，不能区分同一台主机上面的多个端口。squid2.6 为了保持和以前 cache_peer 语法的兼容性，加了一个 name 的参数来搞定这个。搞的整个语法看起来很难受。其实依我说，这次反正都已经改了好多了，不如借此机会再规范化一下算了。

关于 squid 2.6 升级的配置细节，可以参考这里

闲话少说，直接 rpm -U 上去，升级就算完成了。看起来访问是没有什么问题。而且 CPU 占用特别低。以前都保持在 30% 以上，现在最强的时候也只有 1x%。不禁心里暗爽，这新东西还是很好的嘛。

几个小时以后，偶尔上了一下 web 发现相当慢，在 dmesg 里面发现了很多 Drop request 的纪录，知道坏事了。重起一下只能顶几分钟，请求到 450 QPS 的时候一定会开始丢请求。只好恢复成 2.5，于是一切都恢复正常了。

虽然 2.5 还是可以用，但是心里面还是很不甘心的，于是找 squid 之王又要了一个编译参数，禁止掉 fc6 rpm 里面的无聊 patch，禁止掉 coss 存储之类用不到的破东西。重新编译了一下 squid ，再次换回来，问题依旧。

最后这次 squid 升级以失败告终，但是我还是不太明白发生了什么事情。猜测了几种可能。

1：squid 2.6 的新网络代码有什么问题。不能够及时 accept 请求，而是阻塞在其他什么操作里面了。
2: squid 2.6 从 3.0 移植过来的网络代码太高效了，导致把请求总是可以迅速发送到后端 web server，对 webserver 造成了太大冲击。

谁还有用 squid 2.6 的，有没有遇到类似的问题啊？