Squid中文权威指南第八章

第8章 高级磁盘缓存主题
8.1 是否存在磁盘I/O瓶颈？
Web缓存器例如
[url=javascript:;]squid[/url]
，通常在磁盘I/O变成瓶颈时，不会正确的体现和告知你。代替的是，随着负载的增加，响应时间和/或命中率会更低效。当然，响应时间和命中率可能因为其他原因而改变，例如网络延时和客户请求方式的改变。
也许探测cache性能瓶颈的最好方式是做压力测试，例如Web Polygraph。压力测试的前提是你能完全控制环境，消除未知因素。你可以用不同的cache配置来重复相同的测试。不幸的是，压力测试通常需要大量的时间，并要求有空闲的系统（也许它们正在
[url=javascript:;]使用[/url]
中）。
假
如你有资源执行squid压力测试，请以标准的cache工作负载开始。当你增加负载时，在某些点上你能看到明显的响应延时和/或命中率下降。一旦你观察
到这样的性能降低，就禁止掉磁盘缓存，再测试一次。你可以配置squid从来不缓存任何响应（使用null存储机制，见8.7章）。代替的，你能配置工作
负载到100%不可cache响应。假如不使用cache时，平均响应时间明显更好，那么可以确认磁盘I/O是该水平吞吐量的瓶颈。
假如你没有时间或没有资源来执行squid压力测试，那么可检查squid的运行时统计来查找磁盘I/O瓶颈。cache管理器的General Runtime Information 页面（见14章）会显示出cache命中和cache丢失的中值响应时间。
Median Service Times (seconds)  5 min    60 min:
        HTTP Requests (All):   0.39928  0.35832
        Cache Misses:          0.42149  0.39928
        Cache Hits:            0.12783  0.11465
        Near Hits:             0.37825  0.39928
        Not-Modified Replies:  0.07825  0.07409
对健壮的squid缓存来说，命中显然快于丢失。中值命中响应时间典型的少于0.5秒或更少。我强烈建议你使用SNMP或其他的网络监视工具来从squid缓存采集定期测量值。如果平均命中响应时间增加得太明显，意味着系统有磁盘I/0瓶颈。
假如你认为产品cache面临此类问题，可以用前面提到的同样的技术来验证你的推测。配置squid不cache任何响应，这样就避开了所有磁盘I/O。然后仔细观察cache丢失响应时间。假如它降下去，那么你的推测该是正确的。
一旦你确认了磁盘吞吐能力是squid的性能瓶颈，那么可做许多事来改进它。其中一些方法要求重编译squid，然而另一些相对较简单，只需调整Unix文件系统。
8.2 文件系统调整选项
首先，从来不在squid的缓存目录中使用RAID。以我的经验看，RAID总是降低squid使用的文件系统的性能。最好有许多独立的文件系统，每个文件系统使用单独的磁盘驱动器。
我发现4个简单的方法来改进squid的UFS性能。其中某些特指某种类型的操作系统例如BSD和Linux，也许对你的平台不太合适：

• 1.某些UFS支持一个noatime的
  [url=javascript:;]mount[/url]
  选项。使用noatime选项来mount的文件系统，不会在读取时，更新相应的i节点访问时间。使用该选项的最容易的方法是在/etc/fstab里增加如下行：# Device            Mountpoint    FStype  Options        Dump    Pass#

  标签：

  版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
  特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有