介绍：局域网内网站的速度有点慢，网络带宽大多数都被p2p占用了，但是由于某些网站的视频用p2p技术，所以不能完全禁止p2p，所以只好在缓存服务器上做文章。
1、先是测试了一把nginx的正向代理功能，虽然对多CPU支持好一些，但整体效果不好，主要表现在：
（1）nginx不能区分文件的大小，所有文件都做缓存，我监控的最夸张的一个，是一个15G的电影，尽管超出了cache的最大范围，但是nginx还是坚持下载完。这不仅给磁盘带来很大负担，而且长时间占用了大量带宽，等于变相减慢了其他客户的速度。比较理想的状况是，控制文件大小，主要缓存图片、css、html、js等小文件，以及小的rar、zip、doc、pdf等，对于大一些的文件，最好还是让客户端自已去挤nat服务器。
nginx的解决方法是通过不同的locate，把不同的文件区别对待，但是最终还必须有一个locate / ，否则还是不能显示完整的网页，或者干脆打不开网页。
（2）nginx的磁盘性能很差，缓存上万个文件的时候，就明显变慢，磁盘IO长时间保持100%，拖慢了整个系统速度。即使nginx可以多定义cache，用locate把不同文件类型放进不同的磁盘，但是由于nginx没有良好的磁盘机制，一旦一个磁盘中的文件达到上万后，磁盘IO很快就成为瓶颈，磁盘一直是100%。
（3）nginx的DNS查询量非常大，会被防火墙block掉。
（4）nginx没有良好的状态监控工具，找系统的瓶颈比较难，大多数时候靠猜测和抓包分析。
2、varnish，做正向代理力不从心，网上也没找到做正向代理的例子，忽略之。
3、改用传统的squid，以前只是小范围用，机器上千的环境，必须拿出12分的注意力来搞了。
（1）squid可以定义代理的文件大小，这点正符合我们的要求。
maximum_object_size 4 MB
maximum_object_size_in_memory 2 KB
这个正好定义最大缓存大小，超过大小的squid好像是通过正常的nat去下载（？？？测试？？！！！）。对于网页，一般文件大小是20k左右，4兆大小就可以缓存大多数的小文件，至于电影、软件等，缓存的意义不大。
（2）自带了squidclient工具，可以很好地分析系统的瓶颈。
（3）支持多种磁盘系统，从最基本的ufs到aufs、diskd、coss等，ufs相当于直接用系统读写，最开始测试使用时，有大量的unlinkd，并且磁盘很容易到100%，大量的io把磁盘拖垮。我用的是320M的scsi，到300t/s的时候，大约是10MB/s，虽然CPU利用率和内存利用率都不高，中断也不是很高，但是系统基本上处于停止状态，在800台机器的情况下，最大输出10MB/s，在squidclient中，有大量的aborted，说明系统已经饱和，查看store_io，发现有超过十分之一的failed，说明磁盘已经成为系统的瓶颈。
（4）diskd在FreeBSD9.0中，老是dump，测试没通过。
（5)coss模式还是比较好的，
#cache_dir coss /web/coss0 2000 max-size=100000 block-size=2048 overwrite-percent=50 membufs=100
#cache_dir coss /home/coss0 2000 max-size=800000 block-size=2048 overwrite-percent=50 membufs=100
在这个模式下，还是比较不错的，但是文件数达到几十万的时候，磁盘性能也出现下降的趋势，磁盘也处于100%的busy之中，对它只进行了两个磁盘的测试，估计用三、四块的时候，情况会有所改善。
（6)aufs模式，性能不错，也比较稳定，目前状态：
Connection information for squid:
Number of clients accessing cache: 800
Number of HTTP requests received: 2276332
Number of ICP messages received: 0
Number of ICP messages sent: 0
Number of queued ICP replies: 0
Request failure ratio: 0.00
Average HTTP requests per minute since start: 6100.2
…………
Internal Data Structures:
1225098 StoreEntries
57947 StoreEntries with MemObjects
57868 Hot Object Cache Items
1205423 on-disk objects
性能仍然不错。
4、squid优化方案
（1）常用的squidclient命令：
mgr:info
Request failure ratio:失败率，主要跟网络有关
Request Hit Ratios:命中率，如果太低（<20%），就没有意义了
Storage Swap size:磁盘上文件的总大小
Cache Misses: 0.12106 0.15048
Cache Hits: 0.00091 0.00091
这两项的对比，如果接近，就说明缓存系统已经不起作用
Number of file desc currently in use: 使用的文件句柄数，我的经验是到3000以上时，系统就会明显慢下来。（？？？刚加磁盘，等待验证跟数的关系）
Files queued for open: 如果两位数以上，就加或去掉squid吧，它已经成为累赘。
mgr:io 网上的优化方案没见过用它，但我觉得它最有用，可以分析缓存文件的大小，以此来调节缓存区的最大文件体积，如果有多个硬盘，可以把它们平均分一下。我用了三块硬盘，第一块最大限制为1536（3个扇区大小，再大了浪费空间了，不知道aufs有没有特殊的机制？？？），对应机率差不多为30，第二块为6680，第三块由于文件体积比较大，所以机率少分配一点，长期观察，第三块闲得多点，所以把第三块跟系统盘放一起：
number of reads: 6919199
Read Histogram:
1- 1: 725 0%
2- 2: 1091 0%
3- 4: 316 0%
5- 8: 628 0%
9- 16: 1538 0%
17- 32: 4510 0%
33- 64: 19317 0%
65- 128: 67065 1%
129- 256: 285571 4%
257- 512: 314122 5%
513- 1024: 245197 4%
1025- 2048: 1569399 23% 此段用的最多，把这单独放到一个磁盘上
2049- 4096: 1396080 20%
4097- 8192: 1408089 20%
8193-16384: 811719 12%
16385-32768: 347989 5%
mgr:store_io 还是磁盘
create.select_fail 0
create.create_fail 0
（2）替换机制，由于是针对小文件，就用heap吧，网上资料不多，但是说明上说对小文件更有效：
cache_replacement_policy heap GDSF
memory_replacement_policy heap GDSF
（3）日志，还是关了吧。如果没有特殊要求，不需要记录客户端的网址，也不需要进行分析，关了要清静不少：
access_log none
cache_store_log none
5、FreeBSD的必用工具：
top：查看squid的利用率，如果频繁出现io，那么就去处理磁盘吧；
iostat ： 查看磁盘的使用情况
systat -vm 磁盘的busy程度；中断的数量
netstat -m 查看mbuf
vmstat -i 中断数，特别注意中断风暴
rate -i em0 -f "port 80" -Rb 查看通过代理的数据包和流量统计
6、总结：缓存服务器，最主要的还是要优化好磁盘，当然内存足够大除外——现实情况是：机器只有1G内存！