meisw's blog

Squid优化(一)

Hot!几个SQUID重要参数：

maximum_object_size 是 能cache最大的文件大小。对应wmv，rm文件，建议设置为32768 kB
maximum_object_size_in_memory 是在内存中cache的最大文件大小。
cache_mem 是SQUID可用到的最大内存。经实践，4G内存的服务器用2G；超过2G导致SQUID运行不稳

首先要分析SQUID所cache内容：

运行

squidclient -p 80 cache_object://localhost/info

能看到如下内容：

Storage Swap size: 7549104 KB
Storage Mem size: 418804 KB
Mean Object Size: 160.46 KB

Mean Object Size是平均内容大小，一般要把maximum_object_size_in_memory设置成离它最近的128的倍数。在这个例子中maximum_object_size_in_memory 的值应该是256kB。

cache_mem 一般设置成服务器内存的一半或更多，只要运行过程中LINUX没有使用SWAP就可以。

再就是按业务分SQUID。
比如某个论坛，用户能上载图片和视频；当然我们要把上载的图片、视频放在单独的域名上，比如img.example.com, video.example.com；这两个域名只提供静态文件服务。

根据统计，图片的平均大小在100KB，视频的平均大小在4M，差别是很大，应该建两个squid分别作图片和视频的CACHE。图片SQUID的 maximum_object_size_in_memory 设置为256KB，视频的SQUID的maximum_object_size_in_memory设置为8196KB。

Squid优化(2)

Hot!探讨动态内容的CACHE。

BBS，论坛是典型动态内容，要保证内容更新及时的同时，提高访问速度，降低数据库负担不是个简单任务。经实践发现如下办法取得很好效果：

1) 配置SQUID，对动态内容强制CACHE，用到的配置参数是refresh_pattern

refresh_pattern ^/forum/viewthread.php 1440 1000% 1440 ignore-reload

/forum/viewthread.php的内容将强制保持1天

2) 修改论坛程序在用户回复帖子后，向SQUID发送PURGE命令清除相应帖子的页面CACHE，保证失效性
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~实现过这一功能,但是有时候生效,有时候无效,还未进一步查明原因.(Edit by Sean)

3) 有些频繁更新的页面可以不CACHE，用no_cache参数

acl no_forum_cache urlpath_regex ^/forum/forumdisplay.php
no_cache DENY no_forum_cache

Squid 中 refresh_pattern 的作用

用于确定一个页面进入cache后，它在cache中停留的时间。refresh_pattern 规则仅仅应用到没有明确过时期限的响应。原始服务器能使 用 Expires 头部，或者 Cache-Control:max-age 指令来指定过时期限 ，只要没有在设置 override-expire。

语法：

refresh_pattern [-i] regexp min percent max [options]

 min 参数是分钟数量。它是过时响应的最低时间限制。如果某个响应驻留在 cache 里的时间没有超过这个最低限制，那么它不会过期。类似的，max 参数是存活响应的最高时间限制。如果某个响应驻留在 cache 里的时间高于这个最高限制，那么它必须被刷新。

在最低和最高时间限制之间的响应，会面对 squid 的最后修改系数 LM-factor 算法 LM-factor=(response age)/(resource age)。对这样的响应，squid 计算响应的年龄和最后修改系数，然后将它作为百分比值进行比较。响应年龄简单的就是从原始服务器产生，或最后一次验证响应后，经历的时间数量。源年龄在 Last-Modified 和 Date头 部之间是不同的。LM-factor 是响应年龄与源年龄的比率。这个基本不用详细了解，这是不是一个精确控制过期的参数，如果要精确控制过期，就不要使用这个。

Refresh_pattern 有14个参数

我讲讲常用的几个参数的意思

override-expire
该选项导致 squid 在检查 Expires 之前，先检查 min 值。这样，一个非零的 min 时间让 squid 返回一个未确认的 cache 命中，即使该响应准备过期。

override-lastmod
改选项导致 squid 在检查 LM-factor 百分比之前先检查min ，它生效在expire 之后

reload-into-ims
该选项让 squid 在确认请求里，以 no-cache 指令传送一个请求。换句话说，squid 在转发请求之前，对该请求增加一个 If-Modified- Since 头部。注意这点仅仅在目标有 Last-Modified 时间戳时才能工作。外面进来的请求保留 no-cache 指令，以便它到达原始服务器。
一般情况可以使用 reload-into-ims。它其实是强行控制对象的超时时间，这违反了http协议的精神，但是在带宽较窄的场合，可以提高明显系统相应时间。
举例：

refresh_pattern -i \.css$ 1440 50% 129600 reload-into-ims
refresh_pattern -i \.xml$ 1440 50% 129600 reload-into-ims
refresh_pattern -i \.html$ 1440 90% 129600 reload-into-ims-
refresh_pattern -i \.shtml$ 1440 90% 129600 reload-into-ims
refresh_pattern -i \.hml$ 1440 90% 129600 reload-into-ims
refresh_pattern -i \.jpg$ 1440 90% 129600 reload-into-ims
refresh_pattern -i \.png$ 1440 90% 129600 reload-into-ims
refresh_pattern -i \.gif$ 1440 90% 129600 ignore-reload
refresh_pattern -i \.bmp$ 1440 90% 129600 reload-into-ims
refresh_pattern -i \.js$ 1440 90% 129600 reload-into-ims

 ignore-reload
该选项导致 squid 忽略请求里的任何 no-cache 指令。
所以。如果希望内容一进入 cache 就不删除，直到被主动 purge 掉为止，可以加上 ignore-reload 选项,这个我们常用在mp3,wma,wmv,gif之类。
Examples:

refresh_pattern -i \.mp3$ 1440 50% 2880 ignore-reload
refresh_pattern -i \.wmv$ 1440 50% 2880 ignore-reload
refresh_pattern -i \.rm$ 1440 50% 2880 ignore-reload
refresh_pattern -i \.swf$ 1440 50% 2880 ignore-reload
refresh_pattern -i \.mpeg$ 1440 50% 2880 ignore-reload
refresh_pattern -i \.wma$ 1440 50% 2880 ignore-reload

ignore-no-cache
该选项导致 Squid 强制忽略从源站而来的“Pragma: no-cache”和“Cache-control: no-cache”

ignore-private
该选项导致 Squid 强制忽略从源站而来的“Cache-control: private”

ignore-auth：强制将一个请求认为是源站发送的带有“Cache-control: public”

ignore-auth
该选项导致 Squid 强制将一个请求认为是源站发送的带有“Cache-control: public”

Refresh_pattern  percent 的计算

resource age =对象进入cache的时间-对象的last_modified
response age =当前时间-对象进入cache的时间
LM-factor=(response age)/(resource age)

举个例子,这里只考虑percent, 不考虑min 和max

例如：refresh_pattern 20%

假设源服务器上www.aaa.com/index.htm —–lastmodified 是 2007-04-10 02:00:00
squid上 proxy.aaa.com/index.htm index.htm进入cache的时间 2007-04-10 03:00:00

1）如果当前时间 2007-04-10 03:00:00
resource age =3点-2点=60分钟
response age =0分钟
index.htm还可以在cache停留的时间(resource age)*20%=12分钟
也就是说，index.htm进入cache后，可以停留12分钟，才被重新确认。

2）如果当前时间 2007-04-10 03:05:00
resource age =3点-2点=60分钟
response age =5分钟
index.htm还可以在cache停留的时间(resource age)*20%=12分钟-5=7
LM-factor=5/60=8.3%<20%

一直到2007-04-10 03:12:00 LM-factor=12/60=20% 之后，cache中的页面index.htm终于stale。
如果这时没有 index.htm 的请求，index.htm 会一直在缓存中，如果有 index.htm 请求，squid 收到该请求后，由于已经过期， squid 会向源服务器发一个 index.htm 是否有改变的请求，源服务器收到后，如果 index.htm 没有更新，squid 就不用更新缓存，直接把 缓存的内容放回给客户端，同时，重置对象进入 cache 的时间为与源服务器确认的时间，比如 2007-04-10 03:13:00，如果正好在这个后重新确认了页面。重置后，resource age 变长，相应在 cache 中存活的时间也变长。

如果有改变则把最新的 index.htm 返回给 squid,squid 收到会更新缓存，然后把新的 index.htm 返回给客户端,同时根据新页面 中的Last_Modified 和取页面的时间，重新计算 resource age，进一步计算出存活时间。

实际上，一个页面进入 cache 后，他的存活时间就确定了，即 (resource age) * 百分比，一直到被重新确认。

转

http://www.oidview.com/mibs/3495/SQUID-MIB.html

aufs存储机制已经发展到超出了改进squid磁盘I/O响应时间的最初尝试。"a"代表着异步I/O。默认的ufs和aufs之间的唯一区别，在于I/O是否被squid主进程执行。数据格式都是一样的，所以你能在两者之间轻松选择，而不用丢失任何cache数据。

aufs使用大量线程进行磁盘I/O操作。每次squid需要读写，打开关闭，或删除cache文件时，I/O请求被分派到这些线程之一。当线程完成了I/O后，它给squid主进程发送信号，并且返回一个状态码。实际上在squid2.5中，某些文件操作默认不是异步执行的。最明显的，磁盘写总是同步执行。你可以修改src/fs/aufs/store_asyncufs.h文件，将ASYNC_WRITE设为1，并且重编译squid。

aufs代码需要pthreads库。这是POSIX定义的标准线程接口。尽管许多Unix系统支持pthreads库，但我经常遇到兼容性问题。aufs存储系统看起来仅仅在Linux和Solaris上运行良好。在其他操作系统上，尽管代码能编译，但也许会面临严重的问题。

为了使用aufs，可以在./configure时增加一个选项：
% ./configure --enable-storeio=aufs,ufs

严格讲，你不必在storeio模块列表中指定ufs。然而，假如你以后不喜欢aufs，那么就需要指定ufs，以便能重新使用稳定的ufs存储机制。
假如愿意，你也能使用—with-aio-threads=N选项。假如你忽略它，squid基于aufs cache_dir的数量，自动计算可使用的线程数量。表8-1显示了1-6个cache目录的默认线程数量。
Table 8-1. Default number of threads for up to six cache directories
cache_dirs Threads
1 16
2 26
3 32
4 36
5 40
6 44

将aufs支持编译进squid后，你能在squid.conf文件里的cache_dir行后指定它：
cache_dir aufs /cache0 4096 16 256

在激活了aufs并启动squid后，请确认每件事仍能工作正常。可以运行tail -f store.log一会儿，以确认缓存目标被交换到磁盘。也可以运行tail -f cache.log并且观察任何新的错误或警告。


8.4.1 aufs如何工作

Squid通过调用pthread_create来创建大量的线程。所有线程在任何磁盘活动之上创建。这样，即使squid空闲，你也能见到所有的线程。
无论何时，squid想执行某些磁盘I/O操作（例如打开文件读），它分配一对数据结构，并将I/O请求放进队列中。线程循环读取队列，取得I/O请求并执行它们。因为请求队列共享给所有线程，squid使用独享锁来保证仅仅一个线程能在给定时间内更新队列。

I/O操作阻塞线程直到它们被完成。然后，将操作状态放进一个完成队列里。作为完整的操作，squid主进程周期性的检查完成队列。请求磁盘I/O的模块被通知操作已完成，并获取结果。

你可能已猜想到，aufs在多CPU系统上优势更明显。唯一的锁操作发生在请求和结果队列。然而，所有其他的函数执行都是独立的。当主进程在一个CPU上执行时，其他的CPU处理实际的I/O系统调用。


8.4.2 aufs发行
线程的有趣特性是所有线程共享相同的资源，包括内存和文件描述符。例如，某个线程打开一个文件，文件描述符为27，所有其他线程能以相同的文件描述符来访问该文件。可能你已知道，在初次管理squid时，文件描述符短缺是较普遍问题。Unix内核典型的有两种文件描述符限制：
进程级的限制和系统级的限制。你也许认为每个进程拥有256个文件描述符足够了（因为使用线程），然而并非如此。在这样的情况下，所有线程共享少量的文件描述符。请确认增加系统的进程文件描述符限制到4096或更高，特别在使用aufs时。

调整线程数量有点棘手。在某些情况下，可在cache.log里见到如下警告：
2003/09/29 13:42:47| squidaio_queue_request: WARNING - Disk I/O overloading

这意味着squid有大量的I/O操作请求充满队列，等待着可用的线程。你首先会想到增加线程数量，然而我建议，你该减少线程数量。

增加线程数量也会增加队列的大小。超过一定数量，它不会改进aufs的负载能力。它仅仅意味着更多的操作变成队列。太长的队列导致响应时间变长，这绝不是你想要的。

减少线程数量和队列大小，意味着squid检测负载条件更快。当某个cache_dir超载，它会从选择算法里移除掉（见7.4章）。然后，squid选择其他的cache_dir或简单的不存储响应到磁盘。这可能是较好的解决方法。尽管命中率下降，响应时间却保持相对较低。


8.4.3 监视aufs操作

Cache管理器菜单里的Async IO Counters选项，可以显示涉及到aufs的统计信息。它显示打开，关闭，读写，stat，和删除接受到的请求的数量。例如：
% squidclient mgr:squidaio_counts
...
ASYNC IO Counters:
Operation       # Requests
open             15318822
close            15318813
cancel           15318813
write                   0
read             19237139
stat                    0
unlink            2484325
check_callback  311678364
queue                   0

取消(cancel)计数器正常情况下等同于关闭(close)计数器。这是因为close函数总是调用cancel函数，以确认任何未决的I/O操作被忽略。
写(write)计数器为0，因为该版本的squid执行同步写操作，即使是aufs。

check_callbak计数器显示squid主进程对完成队列检查了多少次。

queue值显示当前请求队列的长度。正常情况下，队列长度少于线程数量的5倍。假如你持续观察到队列长度大于这个值，说明squid配得有问题。增加更多的线程也许有帮助，但仅仅在特定范围内。

TCP_IMS_HIT:NONE 客户端发送确认请求，Squid发现更近来的、新鲜的请求资源的拷贝。

Squid发送更新的内容到客户端，而不联系原始服务器。（这指明Squid对本次请求，不会与任何其他服务器（邻居或原始服务器）通信。）

TCP_MEM_HIT:NONE 类似 TCP_IMS_HIT:NONE， 从内存中响应

TCP_REFRESH_HIT:FIRST_UP_PARENT/d

Squid发现请求资源的貌似陈旧的拷贝，并发送确认请求到原始服务器。

原始服务器返回304（未修改）响应，指示squid的拷贝仍旧是新鲜的。或者是重新更新文件。（Squid直接转发请求到原始服务器）

#######2011-03-22 http206 test###

refresh_pattern       -i  \.exe               60      80%     1440  ignore-reload

maximum_object_size 60 MB

range_offset_limit -1

#################################

range_offset_limit这个参数，主要是对各种流媒体和要断点续传的文件的缓存的。 默认是 是

range_offset_limit  0  

squidclient -t 1 -h 127.0.0.1 -p 80 mgr:info

/usr/local/squid/bin/squidclient -p80 -m PURGE URL

首先要明确一下，squid 能够用来作什么。很多人没有搞明白 squid 的工作原理，只是听说 squid 性能不错可以用来给网站提速，就直接在自己的 website 前面套了一个 squid ，这基本没有任何用处，即使你都是静态页面，后面apache上面没有开 mod_expires，一样缓存不了，squid只能起到一个连接管理的用处。

一般说来，网站用 squid 加速，目的有二种

1: squid 本身具有缓存功能，可以将webserver输出的内容缓存起来，在缓存没有过期之前来的访问，都直接用缓存里面的内容，这样可以有效减少 webserver 机器上面的请求数量。这是 squid 的主要功用。
2: 网络慢的用户会长时间占用 webserver 的 TCP 连接，webserver 对每个连接占用的资源比较大，如果长时间不能释放出来服务其他请求，性能会有比较大的影响。前面放一个 squid, webserver 就可以迅速处理完逻辑以后，把数据快速发送给 squid, 然后去处理别的逻辑，而 squid 每个 TCP 连接占用的资源很少，不用担心占用太多资源。这个用途也叫做连接管理，有一些网络设备也可以做这个事情，价格都很贵。

下面针对 squid 的两种功用，来讲述如何调整业务逻辑和 squid 参数

预操作

在搞 squid 之前，不管你用什么编译配置，需要什么特殊选项，都请 –enable-snmp ，并配置好 mrtg 之类，可以图形化的显示 squid 状态，例如 Request Hit Ratio(RHR), Byte Hit Ratio(BHR), 等等，反馈是做一切事情的基础，优化也不例外。

缓存

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 来指定。详细的还是请参考 squid 的配置文件。一般来说，如果后端不是配置很麻烦，建议还是在后端做，前端的配置修改大多数都是违背http协议的，如果出现问题，也比较难排查。

B 根据 squid 访问的模式，进行业务拆分

进行了 Expires Header 的处理以后，squid 就真正可以起到加速的作用了，你可能也能感觉到，网站的访问速度明显加快。但是不要满足于这点成绩，查看 squid 的 snmp 统计图，通常 hit ratio 并不会太高，有 50% 就了不起了。这就是我们需要进一步优化的，我们的目标是让大部分 squid 都达到 9X% 的命中率。

为什么 squid 命中这么低呢，这大概有两种原因。大多数的网站都是有一些页面不能够被缓存的，例如登录页面。这些页面请求也从 squid 走，成为分母的一部分，直接就降低了命中率，我们首先可以做的事情是，把这些不能够缓存的页面请求，拆分到单独一个 squid 上面，或者访问量不大的话，干脆把 apache 暴露出来。这样能够缓存的那个 squid 命中率马上上升一截。

有人可能会说，把不能缓存的页面分拆开去，就光为了让能缓存的那个数字好看，这不是掩耳盗铃么？其实这么做是有意义的，首先就是去掉了不能缓存页面 的干 扰，使得我们进一步优化 squid 的依据更加准确。其次是不可缓存请求和可缓存请求之间的重要性通常是有差距的，分拆了以后，它们之间不容易互相抢占资源，不会因为下载图片的连接太多把 squid 占满，影响更重要的登录请求。第三就是可缓存内容通常是图片等页面元素,　浏览器在 load 它们的时候，对每个站点的并发连接会有控制，如果分开成不同的IP，可以多一些请求同时执行。提高少许显示速度。

其实观察 sohu, sina 之类的页面，你会发现它们的页面也是分拆的，可以看到页面里面的图片都是指向 images.sohu.com 之类的地址，虽然它们可能和其他页面一样后台都指向同一个 apache。

这样做完，缓存命中率大概能上升到 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 个数就可以了.但是并没有实际测试过.

磁盘缓存开多大? 这个问题没有固定答案. 需要经过试验来确定, 一般来说开大一些没有太大问题. 只要你的硬盘足够

转

3. 通过使用多播HTCP包来完成Squid清理，这是MediaWiki目前正在使用的方法，当wiki更新时用于更新全球的Squid缓存服务器，实现原理为：发送PURGE请求到特定的多播组，所有Squid服务器通过订阅该多播组信息完成删除操作，这种实现方式非常高效，避免了Squid服务器处理响应和建立TCP连接的开销。参考资料：Multicast HTCP purging 

发送no-cache头的方式在很多情况下不适用，因为大多数站长都会配置ignore-reload来阻止no-cache和reload头以提高Squid的命中率；通过适当的权限控制PURGE清理将是一种非常简单可行的方式，考虑到安全问题我们可以仅允许特定的主机进行PURGE清理操作，对第1，2种方式进行简单的变通就可以用于管理较大规模数量的前端缓存服务器 - 我们可以在被允许的主机上提供一个专门的后台刷新队列，这个刷新队列在接收到刷新操作时就多线程的向前端服务器发送删除指令，这样就达到了同步刷新的效果。第3种方式没有进行过尝试，因为需要安装相应的补丁，并进行配置，操作成本相对较高，在服务器数量特别巨大的情况下这无疑是一种非常高效的实现方式。

 Refresh_pattern 规则仅仅应用到没有明确过时期限响应。原始服务器能使用Expires 头部，或者使用Cache-Control：max-age指令来设置过时期限，当然在squid主配置文件中配置refresh_pattern 配置任意数量，squid是按照顺序进行查找以匹配正则表达式，。一旦squid找到一个匹配时，squid会使用相应的值来决定，某个缓存响应是存活还是过期，当正则表达式之一被匹配URI时，squid 就会停止搜索

 Refresh_pattern 的语法

 Refresh _pattern [-i] regexp min  percent  max  [Option]

   一 regexp 参数是大小写敏感的正则表达式，- i 选项是忽略大小写，

   三  在min 和max 时间限制之间的响应，会面对squid的最后修改系统LM-factor算法LM-factor=(responseb age)/(resource age). 对这样的响应，squid计算响应的年龄和最后修改系数，然后将它作为百分比值进行比较，响应年龄简单地就是从原始服务器产生，或者是最后一次验证响应后，经历的时间数量。源年龄在Last-Modified 和Date头部之间是不同的，LM-factor 是响应年龄与源年龄的比率。这不是一个精确控制过期的参数，如果要精确控制过期，就不要使用该参数

   四   squid的refresh_pattern 算法的简单描述

       1   如果响应年龄超过refresh_pattern 的max值，该响应过期；

       2  如果LM-factor 少于refresh_pattern 的percent的值。该响应存活

       3  如果响应年龄少于refresh_pattern 的min值，该响应存活

       4  其他情况，响应过期

      Resource age=对象进入cache的时间 – 对象的last_modified

      Response age= 当前时间 – 对象进入cache的时间

      LM-factor   =（response age）/(resource age )

例如 refresh_pattern 20%

    假如源服务器上www.aaa.com/index.html - --lastmodified 是2007-04-10 02:00:00

   1  如果当前时间 2007-04-10 03:00:00

    3  所有说2007-04-10 03:12:00 LM-factor=12/60=20% 之后，cache中的页面index.html 终于stale，如果这段时间没有index.html的请求，index.html会一直缓存中，如果有index.html 请求，squid收到请求后，由于已经过期，squid 会像源服务器发一个index.html是否有改变的请求，如果源服务器收到请求后，如果index.html没有更新，squid就不用缓存，直接会把缓存中的内容给客户端；同时，重置对象进入cache的时间为源服务器确认的时间。比如2007-04-10 03:13:00 ,如果正好在这个后重新确认了页面。重置后，resource age 变长，相应在cache中的cache中存活的时间也同样变长

   1 Override-expire

  2 Override-lastmod

  3 Reload-into-ims

               refresh_pattern -i \.css$ 1440 50% 129600 reload-into-ims

               refresh_pattern -i \.xml$ 1440 50% 129600 reload-into-ims

              refresh_pattern -i \.html$ 1440 90% 129600 reload-into-ims

              refresh_pattern -i \.shtml$ 1440 90% 129600 reload-into-ims

              refresh_pattern -i \.hml$ 1440 90% 129600 reload-into-ims

              refresh_pattern -i \.jpg$ 1440 90% 129600 reload-into-ims

              refresh_pattern -i \.png$ 1440 90% 129600 reload-into-ims

              refresh_pattern -i \.bmp$ 1440 90% 129600 reload-into-ims

              refresh_pattern -i \.js$ 1440 90% 129600 reload-into-ims 

  4 Ignore-reload

 refresh_pattern -i \.mp3$ 1440 50% 2880 ignore-reload

refresh_pattern -i \.wmv$ 1440 50% 2880 ignore-reload

refresh_pattern -i \.rm$ 1440 50% 2880 ignore-reload

refresh_pattern -i \.swf$ 1440 50% 2880 ignore-reload

refresh_pattern -i \.mpeg$ 1440 50% 2880 ignore-reload

refresh_pattern -i \.wma$ 1440 50% 2880 ignore-reload

 5 Ignore-no-cache

 6 Ignore-private

 7 Ignore-auth

 8 Ignore-no-store

     a no-store directive from the Web server which makes an object non-cacheable is ignored.  

 9 Refresh-ims

       a refresh request from a client is converted into an If-Modified-Since request.

转