车东@博客大巴

上周末在博客大巴邀请了上海几家StartUp公司的朋友做了一次技术交流：VeryCD的科学家们，客齐集，联络家，CDNUnion，安居客和Sun的Startup解决方案专家；

主题1：动态内容的CDN缓存
结论，目前CDN缓存仍然以静态内容为主，动态页面缓存过期/更新策略较复杂；而CDN有purge接口，但现在实际应用较少： 更多缓存服务是为内容永不更新的图片、视频等服务；此外，固态盘代替逐步内存的可能性近期还没有，固态硬盘的仍然价格非常高，I/O的速度也是问题；

主题2： Memcahce的使用
所有网站都用了Memcache，并通过避免对数据库的连接而大大提高了性能（命中率在90%以上）；

关于：多memcahced的分布策略；
客齐集
规模： 在多台前端应用服务器上划出一定空间，
分布规则：使用的是memcached addserver方式由memcache自己进行缓存分布；
单点失败处理：遇到个别节点中断会retry；
博客大巴和VeryCD应用类似：
规模： 几十G（单个2G）；
分布规则：都是自己应用设置设置缓存分布规则，对数据进行分布，
单点失败处理：如果遇到Memcached中断并不尝试其他服务器；

关于memcache的压缩：
PHP客户端可以设置压缩外， server端也有更详细的压缩配置选项（memcached的文档中有？）；
关于memcached的扩展性： 最新版本有考虑consistent hash（在扩展服务节点后，旧内容仍然再旧服务器上，不用按重新按新的分布规则生成新缓存）
memcached： bin模式存储；

对于缓存对象：大的List列表页对象用memcache缓存对效率提升很重要；

主题3： Start up公司的招聘来源
客齐集的校园招聘成果还是让其他公司非常的眼红，另外说一句： 我们仍然在招前端应用开发人员（欢迎应届生）：有优秀的开发人员，各个Startup公司之间都是可以推荐的（VeryCD的51job招聘广告就是托管在博客大巴的）。

以后还会不定期做一些交流： 更多讨论请加入实践讨论组。

在上海可以参加的几个活动： 大部分都在交大徐汇校区；

周一： VeryCD复旦中学 羽毛球活动 晚上8点-10点；周二： 博客大巴 跆拳道 徐汇交大体育馆 晚上7点-8点半；周四： 客齐集 篮球 徐汇交大体育馆2层 晚上7点-9点；周末： 盛大花园 网球场 晚上6-9点 不定；

“我不是塑料袋”是一个很有趣的设计创意： I'm not a plastic bag

此次我不是塑料袋：环保袋设计大赛活动的奖品为：
评委会奖(1名)：MacBook Air + 5000元现金
( 歌手Yael Naim的那首《New Soul》你每天在电梯中都会听到多次吧？ )
独树一帜奖(2名)：价值5000元以上的尼康D60单反相机1台 + 5000元现金
不拘一格奖(2名)：价值2000元以上的多普达S1手机1台 + 5000元现金

* 奖品涉及到的个人所得税由获奖人自理
* 所有参加投票的网友均有机会抽取100名参与奖： BlogBus明信片一套*50套 触动传媒提供小礼品*50个

尝试：
启用了PHP memcache_set()函数中的 MEMCACHE_COMPRESSED压缩选项，而memcache_get()可以在后续读取过程中自动对压缩的缓存对象进行解压缩。

效果：
测试了一下，对于博客大巴目前的应用来说，启用压缩后，相同的容量（2G）存储的对象数量增加了约一倍，缓存命中率从50%左右，提高到了60%左右。进一步提高命中率硬件投入还是必须的，又增加了2倍的内存后终于做到了缓存命中率提高到90%；

前提0： 内存缓存有用，且命中率值得提升；
从60%提高到90%，还是从90%提高到95%，要看hit后的性能能够提升是否值得；

前提1：MemCached已经用满
先用memcached-tool查看一下memcached的容量统计，看memcached是不是已经用满了。如果充分运行时MemCached的空间尚未用满，启用一下压缩是没有意义的； 而且：发现没有用满的MemCached，最好减少相应MemCached的容量，空余出更多内存给其他服务做缓存；

前提2： 压缩率
缓存的数据的确有大于几百字节的，如果都是小于100字节的键值对，压缩可能反而带来膨胀。由于缓存对象的大小在Memcached中都是按照固定大小分块存储的，最小也要88 B。所以对于过小数据带来的压缩膨胀并不是太大的问题；

前台应用的CPU损耗：
对数据的额外压缩CPU损耗远远低于缓存命中率提升减少后台数据库访问带来的性能提升，和http的gzip/deflate压缩类似，压缩后数据一般为原数据大小的30%左右，节省了70%的传输性能消耗所得会大于文件压缩带来的性能损耗；

HTTP 1.1的规范建议所有的请求输出都包含Vary Header，目的是针对对前端缓存服务器，增加针对Vary制定的各种Header类型进行不同的缓存处理，在浏览器规格复杂的情况下，不利于缓存的命中，所以要在被缓存的服务器上设置：

Header unset Vary

 

问题是这样被发现的：最近使用Apache 2.2的内存缓存mod_mem_cache机制进行后台静态文件加速。但是总是发现几乎是只代理而不缓存，而内存缓存模式又没有统计工具查看缓存内容和命中率。转为用mod_disk_cache后，前端缓存目录空间增加非常快，以至于经常需要删除文件，而删除文件的I/O损失超过了直接访问后台访问的加速所得。后台明明只有几M模板图片和CSS文件，为什么缓存空间上G而且命中率那么低呢？查看了一下缓存目录下的文件，Apache的前端磁盘缓存就会根据浏览器除了针对内容的.data文件和.header文件外还有一个.vary目录，而这个vary目录下又会按照顶级的cache规则再mapping出2级目录来，目录节点个数过多造成磁盘空间的浪费：

a/b/Jqyw8OvBIlgaef7Zb8lQ.data
a/b/Jqyw8OvBIlgaef7Zb8lQ.header
a/b/Jqyw8OvBIlgaef7Zb8lQ.header.vary/a/b

当遇到和原有Vary不同的Header时，会在 header.vary目录下生成更多的缓存；从Apache的讨论组上看原因就是IE的AcceptEncoding请求头信息里增加了一个空格；

IE : Accept-Encoding: gzip, deflate
Firefox: Accept-Encoding: gzip,deflate

于是按照Fernando的方法，将后台的Vary Header禁掉了。缓存空间立刻停止了增长（还是个别有header.vary目录出现）。

 

另外一个配置优化是不要启用后台的Expires Header；

ExpiresActive off

由前端的Cache服务器设置缓存规则，基本上到后台的访问就很少了；

 

记录一个调试缓存缓存用命令行看Header输出的方法：
用curl -I 查看HTTP头信息；
查看缓存后输出结果：
curl -I http://www.example.com/foo.bar
查看缓存前的服务器输出：
curl -I -H "Host: www.example.com" http://ip.address.of.example/foo.bar

[chedong]$ curl -I -H "Host: public.blogbus.com" http://192.168.1.17/rss/xianguo.png
HTTP/1.1 200 OK
Date: Sat, 12 Apr 2008 07:09:51 GMT
Server: Apache
Last-Modified: Mon, 28 Jan 2008 03:34:55 GMT
Accept-Ranges: bytes
Content-Length: 1353
Content-Type: image/png

 

[chedong]$ curl -I http://public.blogbus.com/rss/xianguo.png
HTTP/1.1 200 OK
Date: Sat, 12 Apr 2008 07:10:01 GMT
Server: Apache/2.2.8 (Unix)
Last-Modified: Mon, 28 Jan 2008 03:34:55 GMT
Accept-Ranges: bytes
Content-Length: 1353
Cache-Control: max-age=20736000
Expires: Mon, 08 Dec 2008 06:27:41 GMT
Node: B01-AD-01
Age: 2540
Content-Type: image/png