squid优化记及nginx正向代理的缺点

   最近局域网内网站的速度有点慢，网络带宽大多数都被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可以定义代理的文件大小，这点正符合我们的要求。

1. maximum_object_size 4 MB
2. 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模式还是比较好的，

1. #cache_dir coss /web/coss0 2000 max-size=100000 block-size=2048 overwrite-percent=50 membufs=100
2. #cache_dir coss /home/coss0 2000 max-size=800000 block-size=2048 overwrite-percent=50 membufs=100

在这个模式下，还是比较不错的，但是文件数达到几十万的时候，磁盘性能也出现下降的趋势，磁盘也处于100%的busy之中，对它只进行了两个磁盘的测试，估计用三、四块的时候，情况会有所改善。

（6)aufs模式，性能不错，也比较稳定，目前状态：

1. 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
   …………
   
2. Internal Data Structures:
3. 1225098 StoreEntries
4. 57947 StoreEntries with MemObjects
5. 57868 Hot Object Cache Items
6. 1205423 on-disk objects

性能仍然不错。

4、squid优化方案

（1）常用的squidclient命令：
  mgr:info 
 

1. Request failure ratio:失败率，主要跟网络有关
2. Request Hit Ratios:命中率，如果太低（<20%），就没有意义了
3. Storage Swap size:磁盘上文件的总大小
4. Cache Misses: 0.12106 0.15048
5. Cache Hits: 0.00091 0.00091
6. 这两项的对比，如果接近，就说明缓存系统已经不起作用
7. Number of file desc currently in use: 使用的文件句柄数，我的经验是到3000以上时，系统就会明显慢下来。（？？？刚加磁盘，等待验证跟数的关系）
8. Files queued for open: 如果两位数以上，就加或去掉squid吧，它已经成为累赘。

mgr:io 网上的优化方案没见过用它，但我觉得它最有用，可以分析缓存文件的大小，以此来调节缓存区的最大文件体积，如果有多个硬盘，可以把它们平均分一下。我用了三块硬盘，第一块最大限制为1536（3个扇区大小，再大了浪费空间了，不知道aufs有没有特殊的机制？？？），对应机率差不多为30，第二块为6680，第三块由于文件体积比较大，所以机率少分配一点，长期观察，第三块闲得多点，所以把第三块跟系统盘放一起：

1. number of reads: 6919199
2. Read Histogram:
3. 1- 1: 725 0%
4. 2- 2: 1091 0%
5. 3- 4: 316 0%
6. 5- 8: 628 0%
7. 9- 16: 1538 0%
8. 17- 32: 4510 0%
9. 33- 64: 19317 0%
10. 65- 128: 67065 1%
11. 129- 256: 285571 4%
12. 257- 512: 314122 5%
13. 513- 1024: 245197 4%
14. 1025- 2048: 1569399 23% 此段用的最多，把这单独放到一个磁盘上
15. 2049- 4096: 1396080 20%
16. 4097- 8192: 1408089 20%
17. 8193-16384: 811719 12%
18. 16385-32768: 347989 5%

mgr:store_io  还是磁盘

1. create.select_fail 0
2. create.create_fail 0

（2）替换机制，由于是针对小文件，就用heap吧，网上资料不多，但是说明上说对小文件更有效：

1. cache_replacement_policy heap GDSF
2. memory_replacement_policy heap GDSF

（3）日志，还是关了吧。如果没有特殊要求，不需要记录客户端的网址，也不需要进行分析，关了要清静不少：

1. access_log none
2. 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内存！