Squid做的一些小改进

今天炒个现饭，翻出来个3年前做的东西。

1. 按大小区分缓存存放位置。

在做正向代理的场景中，众多客户端访问外部大量网站，会产生海量的小文件小图片缓存，这些小文件缓存若简单的保存于磁盘上的ext3文件系统上，不但大大降低文件系统访问效率，而且频繁的删除过期缓存操作还会触发大量的删除小文件操作，这类操作在ext3文件系统上性能非常低下，而且会拖累整个文件系统的性能。

笔者曾经做过一个实验，在7200转的SATA硬盘的ext3文件系统上，用平均大小为15K的小文件（随机生成，大小呈正态分布）填充2.3G的空间，信息如下：

Store Directory #1 (aufs): /test/squid3
FS Block Size 4096 Bytes
First level subdirectories: 16
Second level subdirectories: 256
Maximum Size: 2560000 KB
Current Size: 2402508 KB
Percent Used: 93.85%
Filemap bits in use: 154459 of 262144 (59%)

对这大约15万个文件（16个一级目录，256个二级目录），我们执行删除操作，用时大概在24秒多。

而同样规模的小文件，存放在基于内存的tmpfs中，删除整个目录的时间不会超过1秒。而且在内存中进行小文件的随机访问也非常快。

那么，这就对squid的配置提出了要求，可以考虑使用Squid配置中cache_dir的选项max-size和min-size。Squid3在3.0和3.1中，cache_dir的可配置项只有简单的max-size，没有继承2.6/2.7中成对的max-size和min-size。而从3.2开始，开发人员移植了min-size。这样，可以这么进行配置：

cache_dir aufs /dev/shm 4096 16 256 max-size=102400
cache_dir aufs /disk/cache 40960 16 256 min-size=102400

按照这个配置，大于100K的对象就会被缓存进磁盘缓存而小于100K的文件都会只保留在内存缓存。

注意，这里的tmpfs内存缓存和cache_mem配置的内存缓存不一样，cache_mem只是cache_dir的上一级缓存，是cache_dir的子集。

如果你要对Squid3.1和3.0进行代码修改，那么只需关注这么几个文件和函数：

SwapDir.cc 修改SwapDir::optionMaxSizeParse()，让这个函数同时处理max-size和min-size这两个配置选项。

store_dir.cc 修改SwapDir::objectSizeIsAcceptable()，在进行缓存时，通过对象大小判断是否应该缓存进当期的缓存Dir。

2. 按照文件类型区分缓存位置

如果要对缓存对象进行进一步的细分，那么还可以针对缓存对象不同的文件类型进行区分。例如，专门将大的视频文件放到大容量但性能要求不高的硬盘上进行缓存，或者专门将图片文件或者可执行程序对象缓存到指定目录同时指定一个较长的更新周期，以便于日后进行审计。

这样的话，需要对Squid的代码进行修改。通过修改以下文件，可以实现在cache_dir配置项上增加content-type这一个选项，指定缓存目录专门缓存某一种或多种文件类型:

SwapDir.cc 修改SwapDir::getOptionTree()增加新的配置选项处理函数。参照optionMaxSizeParse(),我们可以构造一个新的optionObjectTypeParse()函数处理对象类型的处理函数。

store_dir.cc 增加函数SwapDir::objectTypeIsAcceptable(）以处理缓存对象的文件类型。可参考上述的objectSizeIsAcceptable()。

3. 使用SSD硬盘做为Squid缓存

SSD硬盘的特征就是读取超快，但是随机写性能一般，而且大量的写入会严重降低SSD的寿命。

在正向代理场景下，有限的客户端通过代理访问无限的外部网络，Squid的缓存会有很高的更新率，这种情况下，使用SSD硬盘不是一个很好的选择。

在网站做反向代理的场景下（CDN就是这类场景），Squid缓存的热门对象往往在一个时期比较固定，例如热门的图片和热门的视频。这时候采用SSD做为缓存介质就能对性能进行大幅提升。如果还能修改Squid，对缓存的更新算法进行调整，例如以访问频率热门度为指标进而不是用最后访问时间为指标进行缓存更新，可以一定程度的提高SSD缓存的寿命。