用了很长时间的squid服务，今天抽空总结一下，squid优化的方向：
    squid的功能，总结起来，有两个主要功能：
    1、将web server输出的内容缓存起来，在缓存没有过期之前来的访问，都直接用缓存里面的内容，这样可以有效减少web server上面的请求数量。
    2、减轻 web server 负载的压力和提高web server 的安全系数； squid 每个 TCP连接占用的资源很少，这个用途也叫做连接管理（这个功能某些硬件设备也能实现这个功能，但是一般价格太贵了）。
   
    针对 squid 的两种功用，来讲述如何调整业务逻辑和 squid 参数：
    关于缓存问题：
    A、使用 Expires header 来控制缓存
  squid在缓存webserver内容的时候，需要后端webserver输出一些控制信息告诉他页面是不是可以被缓存，以及可以缓存多久。否则squid 是不会自作主张给你缓存内容的。一个页面到底能不能缓存，只有开发网站的人才知道，因此开发人员有责任在动态页面里面输出Expires 和 Cache-Control header。简单举一个 php 的例子以说明这两个 header的值是什么含义，其中$expiretime 的单位是秒。
header("Expires: " . gmt_date_format(time()+$expiretime));
header("Cache-Control: max-age=" . "$expiretime");
对于静态文件，有两种方式来让 squid 自动给静态文件缓存，一种是使用 apache 的 mod_expires，可以针对路径或者针对文件类型/扩展名来自动输出 cache 头。详细的请参考 mod_expires 的说明 。另一种是用 squid 的refresh_pattern 来指定。
    B、根据 squid 访问的模式，进行业务分类
进行了 Expires Header 的处理以后，squid就真正可以起到加速的作用了，你可能也能感觉到，网站的访问速度明显加快。但是不要满足于这点成绩，查看 squid 的 snmp 统计图，通常hit ratio 并不会太高，有 50% 就了不起了。这就是我们需要进一步优化的，我们的目标是让大部分 squid 都达到 9X%的命中率。
为什么 squid 命中这么低呢，这大概有两种原因。大多数的网站都是有一些页面不能够被缓存的，例如登录页面。这些页面请求也从squid 走，成为分母的一部分，直接就降低了命中率，我们首先可以做的事情是，把这些不能够缓存的页面请求，拆分到单独一个 squid上面，或者访问量不大的话，干脆把 web 暴露出来。这样能够缓存的那个 squid 命中率马上上升一截。有人可能会说，把不能缓存的页面分拆开去，就光为了让能缓存的那个数字好看，这不是掩耳盗铃么？其实这么做是有意义的，首先就是去掉了不能缓存页面的干扰，使得我们进一步优化squid 的依据更加准确。其次是不可缓存请求和可缓存请求之间的重要性通常是有差距的，分拆了以后，它们之间不容易互相抢占资源，不会因为下载图片的连接太多把squid 占满，影响更重要的登录请求。第三就是可缓存内容通常是图片等页面元素,　浏览器在 load它们的时候，对每个站点的并发连接会有控制，如果分开成不同的IP，可以多一些请求同时执行。提高少许显示速度。其实观察 sohu, sina 之类的页面，你会发现它们的页面也是分拆的，可以看到页面里面的图片都是指向images.sohu.com 之类的地址，虽然它们可能和其他页面一样后台都指向同一个 web。这样做完，缓存命中率大概能上升到 70%-80% 了，运气好的时候完全可以上 90%。
另一种导致 squid命中低的原因和这个比较类似，同样都是可缓存的内容，有的可能是软件下载站上面的大文件，有的是新闻站点上面的小图片，如果同一个 squid对这样差别巨大的文件加速的话，会严重干扰 squid 的缓存策略，两者不能兼顾，要不就是大文件占据了 cache ，把小文件都挤出了cache, 要不就是小文件特别多，大文件无法进入 cache, 导致大文件经常 miss。这个比不能缓存的页面还要恶心，因此即使在服务器资源有限的情况下，也要优先拆分这两类型访问。一般来说，文件大小分界线定在 1M左右就可以了，如果是有软件下载这样特别大的文件，可以在 4M - 10M 左右再拆分一次。对于不同访问类型的 squid,其系统优化参数也会有所不同.只要悉心按照访问模式来拆分业务，大部分起缓存作用的 squid 都可以达到很高的命中率，至少都可以到达 9X%。
 
C 根据不同的需求，调整参数优化缓存
完成 A 和 B 两步优化以后， squid 的命中率经常可以达到 9x%, 可以说我们已经给 squid
创造了非常优秀的外部环境，下面我们就要从 squid 本身入手，通过调整它的缓存参数和缓存策略，甚至系统的参数，来让 squid
发挥出更好的性能。在 B 步骤中，我们把 squid 划分成了三种用途，缓存大文件，缓存小文件，不缓存文件，这其中最后一种用途情况下面 squid不起到缓存效果，只用来做连接管理，因此我们把它放到后面的连接管理里面叙述，这里只讨论和缓存相关的 squid 参数。squid 有内存缓存和磁盘缓存两级缓存, 通常来说, 只要是专门给 squid 用的机器, 内存缓存都建议开得比较大,大内存缓存总是有好处的嘛, 但是注意不要使得系统开始吃 swap ,像Linux这样一开始吃 swap 性能就下降比较严重的系统尤其要注意.这个程度需要自己试验确定.通常 1G 内存的Linux机器用来跑 squid ,内存缓存可以开到 512M.有些libc比较差的平台, 例如比较老的 freebsd 系统, 其 malloc 函数的质量不高,可能会造成比较多的内存碎片,导致squid 运行一段时间以后分配不出来内存挂掉. 这时候推荐在编译时候使用 dlmalloc package. 即使如此, 仍然要再缩小squid 的内存缓存,以防不幸发生.磁盘缓存的情况比较复杂, squid 有 ufs, aufs, coss, diskd, null 五种存储后端, 其中 ufs,aufs, diskd 都是在文件系统上面保存很多小文件, coss 是 squid自己实现了一个简单的文件系统,可以使用一个大文件或者一个磁盘设备来存储. null 则是给不想要磁盘缓存的情况准备的. coss看起来好像比较拽, 但是以前试验并不足够稳定,因此并不推荐使用. 剩下的三种存储方式,具体选择哪种需要根据操作系统的特性来进行.
ufs 是最传统的存储方式, 我们知道, squid 是一个单进程的程序, 它使用 ufs 存储后端时, 直接在进程里面读写文件.这是一种很简单的方式, 缺点是当读写磁盘被阻塞的时候, squid 不能够处理请求, 会造成服务质量波动比较大. 因此出现了 aufs 和diskd 两种存储后端, 原理都是 squid 主服务循环不负责读写文件,而是通过消息队列或者tcp/pipe连接将数据传送给其他的线程(aufs)/进程(diskd), 然后其他线程/进程进行读写.
很显然,这两种存储方式有一定的通信开销, 因此不一定就比 ufs 好, 需要具体问题具体分析前面说到, ufs/aufs/diskd都是在文件系统上面存储很多小文件,因此文件系统本身的特性严重影响了squid缓存的性能,对于Linux ,强烈推荐用 reiserfs 等适合处理小文件的文件系统, bsd 则至少要打开 softupdate, 以及 dirhash
等一切对很多小文件有好处的选项. 在比较新的系统上面, reiserfs 等文件系统的性能已经足够优越, 通常 ufs 就已经可以应付需要.对于一些老系统,使用 aufs 或者 diskd 是比较好的选择,如果系统的线程库比较好(如Linux,Solaris),那么使用aufs, 否则 diskd.也有一些例外情况, 比如多 cpu 的 Linux 2.6 系统, 线程库很优秀, 虽然 ufs 本身已经比较快了,但是 squid单进程无法利用另外的 cpu , 不如使用 aufs , 让另外的 cpu 也可以起到一些作用, aufs在编译的时候可以选择使用几个读写线程. 这个个人觉得稍微超过 cpu 个数就可以了.但是并没有实际测试过.磁盘缓存开多大? 这个问题没有固定答案. 需要经过试验来确定, 一般来说开大一些没有太大问题. 只要你的硬盘足够。
 
  
   D、缓存策略
一般来说，（缓存策略）如果后端不是配置很麻烦，建议还是在后端做，前端的配置修改大多数都是违背 http
协议的，如果出现问题，也比较难排查。HTTP 缓存协议比较权威的可以参考 RF2616 第十三章，特别是 13.2 和 13.3节。具体实现可以参考比方 Firefox 代码 nsHttpResponseHead.cpp 的 ComputeCurrentAge() 和
ComputeFreshnessLifetime() 函数看看各类情况的处理方式。mod_expires的配置就需要深刻理解这些基本概念，否则可能反而会增加请求数。如果没有特别的理由，静态文件的过期时间一般是设置为 access time加上一定量的时间。这个一定量的时间由具体情况决定。比如网站建设初期，各类静态文件可能需要比较短的过期时间以方便网站更新；而一旦美工敲定图片，图片的过期时间可以大胆的设置为几个月。在配置完成以后如果没有很大的把握也可以实际浏览一下分析请求序列看是否浏览器端和squid 服务器都做到了有效的缓存，特别注意 cache 相关的请求和回复头，包括 squid 提供的 X-Cache 头。 另外，虽然违反 HTTP 协议的 squid 配置一般都不推荐，但是具体到细节上，这也不是绝对的原则。下面举例说说必须违反 HTTP 协议的情况。
* 使用 javascript做镜像网站测速，一般实现方式是从各个镜像站下载一个图片看哪一个最快。最理想的情况是图片在浏览器端不要缓存（以便下次准确测速），但是这个请求又完全没必要打到主服务器上。那么可以在
squid 里针对这个图片 url 配置强制缓存 refresh_pattern reload-into-ims
ignore-reload。当然这个例子很土鳖，只是举个例子。
* reload_into_ims （这里说的是 squid 的配置参数，不是 refresh_pattern 里面的
option）。这个参数虽然违反 HTTP 协议但是对大部分网站来说是可以设置为 on 的，只要后端服务器对
If-Modified-Since 头的判断正确并且没有潜在安全问题即可。
* 浏览器 F5 刷新和 javascript 的 location.reload()
刷新可能会重新请求所有的网页内嵌元素并且可能带 no-cache 请求头，一般来说 reload_into_ims 设置成 on
已经足够保证对主服务器不造成冲击，但是如果有必要可能还是需要在 squid 配置强制缓存。
* 针对土鳖客户端的优化。比如早期的 fterm 预览图片会发送 Pragma: no-cache 的请求头，这势必导致所有
fterm 预览图片的请求如数全部打在后端服务器上，所以解决方法是 squid 这里做手脚针对这类 url
配置强制缓存。一个细节问题是如果不能缓存的图片（比方有察看权限限制的）和能缓存的图片的 url 结构完全一样，那么在 squid强制缓存这类 url 的话又会有潜在的安全问题，这里涉及到后面会讲到的网站结构优化，针对这个问题需要修改网站的代码以明确区分这两类url。还有另外一个例子是早期的 firefox 发送 XMLHttpRequest 请求也会发送 no-cache的头，后来的版本改了。当年这一类 ajax 请求的 url 也是需要配置强制缓存的。* 最后一个问题是，如果在特殊情况下必须同时在后端服务器发送 Expires 头，并且又在 squid 中配置这类 url 的refresh_pattern，那么需要特别小心。比如，如果 squid 强制缓存时间比 mod_expires
配置的过期时间长，那么可能造成 squid 发送已经过期的内容，导致浏览器本来可以有效缓存的内容却需要不断的向服务器检查更新。最后，有些后端服务器没办法配置 mod_expires。这可能是因为没有配置权限，也可能是因为后端服务器软件太土鳖，总之这样的情况下就必须用squid 配置 refresh_pattern 了。
 
  E、网站代码及结构优化
很多 squid 优化（的文章）只限于在 squid
参数和系统参数上面的调整。但是这个实在只是细枝末节的事情，只要不是太弱智的配置导致无法缓存，squid
的性能不会有太大差距。网站优化一般来说也是属于这种类型的优化，对于主服务器负荷瓶颈在磁盘
I/O，或者网络瓶颈是大量大图片文件的情况，优化网站 html 结构可能对性能提升没有半点作用。不过即便如此，有一个为 squid考虑的网站结构，可以使得 squid 服务器的配置比较容易，也可以比较容易的实现多 squid业务分拆，有的时候业务分拆并不是为了性能，而是为了更好的分析问题以便进一步优化网站。下面简要说说有可能提高性能的网站代码优化。* 减少页面大小。这个问题实在是到处都有好文章，我就不详细说了。常见技巧是分离 css/js到单独文件减少动态主页面大小同时保证静态内容有效缓存；页面 layout 设计尽量使用 div+css；有大量冗余 html 元素的部分使用javascript 来输出。最后这个页面 javascript 化可能需要考虑搜索引擎优化 (SEO) 的问题，总的来说需要在减少流量和SEO 之间寻找一个好的平衡点，这个只有做网站的人自己最清楚。* 减少同一份数据的不同表现形式。大量使用 ajax 的站点有时候考虑 SEO 往往要重写一套给搜索引擎看的页面，这势必导致squid 这里要存两套页面。但是如果功力足够还是可以做到大部分页面重用。举例来说，网站可能希望用户读文章不切换页面而使用XMLHttpRequest 载入，这个就可以在 <a href 写上文章内容的页面以便搜索引擎扒站同时也允许用户在新窗口打开这个文章，而onclick 事件则触发 XMLHttpRequest
载入页面并分析显示内容。只要代码写的足够漂亮，这里用一个文章页面就可以实现所有的功能。* 标准化 url。这个可以算前一条的补充。写网站如果不小心，可能同一个资源会有不同的 url。比方某篇文章，从主页进去的 url是 article?bid=3&id=50，从搜索结果进去却是article?id=50&bid=3。这样两个页面，不但影响外部搜索引擎排名（自己和自己打架），更会影响 squid 效率，因为squid 需要单独存这两类页面。* 网站建设初期充分考虑到将来的 squid 优化。举例来说，很多网站都在页面带用户登录信息显示，这样的页面如果不使用javascript 技巧就完全不可以在 squid 这里 cache。而实际上，如果这些动态内容可以在 javascript 里面通过cookie 判断出来，那么完全可以用 javascript 来写。这方面的细节工作做得越好，就有越多的页面可以被 squid安全的缓存。当然这方面的优化有时候也只有网站运行起来才能发现，维护网站的时候多分析
log，多观察，就可以发现这些细小的可以优化的地方，水滴石穿，大量小细节的优化也可以带来可观的性能提升。
 
F、 其他杂题
* 同步 squid 和主服务器的时钟。从原理上说即使主服务器、squid
以及浏览器端的时钟都不同步，应该也不会造成缓存策略上的问题，但是为了防止诡异问题的发生，还是配置一下 squid 和主服务器的 ntpd为好。ntp 是一个极轻量级的协议，现在网络上 ntpd server 也遍地都是，保证服务器时钟准确到 1秒之内也可以保证别的一些程序的事务处理逻辑。* 密切注意搜索引擎的动向。有一些搜索引擎做的比较弱智，有的时候会突然发很多请求过来。搜索引擎扒站很容易扒到冷僻内容，所以即使请求量只是普通浏览用户请求量的零头，也可能会对主服务器造成冲击。大部分搜索引擎还是比较守规矩的，甚至有些搜索引擎公司还可以与他们接触配置扒站方案。不老实的搜索引擎可以通过squid 或者主服务器 log 找出来，特别不老实的可能 iptables 都能发现。解决方法比如可以针对搜索引擎 user agent判断，或者干脆 iptables 咔嚓掉。* Cache replacement policy，对大论坛站点，虽然 lru 算法占用 cpu 较低，但是 servicetime 可能会不如带 dynamic aging 的算法稳定。据观察，lru算法在运行几天之后的早晨如果突然碰到大量新请求，新请求会很难进入cache，或者进入了也很快被踢出，导致非常容易形成恶性正反馈拖垮后台服务器。但是假如每天清晨清 cache，并且保证磁盘 cache的量稍大于每天能存下来的量，那么 lru算法应该也不会比别的算法差（事实上什么算法都一样了）。当然这只是我的一家之言，一般来说这个问题还是需要根据 squid服务器性能和网站具体情况多次反复试验选择最合适的算法。一般来说小规模和超大规模的站点优化这个参数可能不会有什么显著的性能提升，所以不建议耗费太多时间优化这个。* 一定时间清理 cache 并重启 squid。这个有可能只是 squid 2.5并且是高负荷破机器上需要考虑的一个方案。某站曾经有段时间每天高峰期 Miss Service Time
都会飙升，但是主服务器却没有超负荷的现象，最后推测可能是 squid 自己调度的问题。后来每三天清理 cache 并重启 squid似乎大大减少了这种现象。后据权威人士批复，这个可能是因为 squid cache replacement
算法过于古老，不适应高速更新的大型论坛所致。* 多域名宣传的服务器。如果网站允许有多个域名但是所有的域名都指向同一个网站，那么要注意 squid不要配置成多域名模式，否则它会把每个域名的 cache
都分开处理，导致效率低下而且不能有效利用缓存存储空间。题外话，单个网站宣传多个域名也会影响搜索引擎排名等等，所以本质上也是不推荐这么做的。
* maximum_object_size_in_memory，maximum_object_size
这两个参数的配置也是具体问题具体分析的。具体到某站上，常见的大文件就是附件了，由于附件最大允许大小是 5120 KB，所以maximum_object_size 配置了 5123 KB 以保证即使最大的附件加上各 HTTP头也能有效的被缓存。另外maximum_object_size_in_memory 的配置需要考虑网站具体情况和 squid 服务器的性能，这也需要实际试验出来。