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

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

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

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

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

This meme is spreading in the tech/geek blogosphere these days, it’s fun to join.

$ history|awk '{a[$2]++} END{for(i in a){printf "%5d\t%s\n",a[i],i}}'|sort -rn|head
  237   git
   71   ant
   58   ll
   26   cd
   24   gvim
   19   sudo
   17   exit
   11   vi
    5   du
    5   cat

Some notes:

1. I started playing with git last few days, that’s why it reaches the top, and I use esvn for most of Subversion commands, so svn won’t end up here;
2. my laptop disk space is getting filled up, that’s why the du;

Now, what’s in your history?

这篇贴子是《成群结对》系列中的一部分，想要回顾过往文章，请直接看《成群结对》专题页面。现在所讨论的“电子邮件讨论组”是这个系列的第三部分。

上次小容在贴子里建议校园社团使用Google邮件讨论组来进行活动沟通和社团管理，同时简要介绍了Google邮件组的一些设置情况。

今天小容会来回顾自己使用Google邮件讨论的情况。Google提供了完整的统计数据，所以，把这些数据贴图出来就好了：） 如果你有兴趣，也可以盘点一下你的Google邮件讨论组，trackback过来。

• 总体情况

自2005年4月开始使用Google邮件讨论组，已经使用三周年了。参加53个小组，在29个小组中发过贴子，全部发贴量为647次。发贴量最高的时间点是在2006年9月，那个月发贴44次。大部分月份发贴量都在15次以上，大约是每2天1次。会员级别，5颗星。

• 担任创建者的小组

担任5个小组的创建者，其中820名成员的小组是One 2 Many的邮件列表，只是传送信息给订阅的会员，小容有权利给会员发送信息，会员没有权利发送信息给整个邮件组。其余4个邮件组都是Many 2 Many的，每个成员都可以向整个邮件组发送信息。其中成员最少只有2个人，显然小容创建这个小组之后就将它忘记了。拥有19名成员的邮件组很特别，其中很多成员不是很熟练地使用网络工具，但是却是小容在现实生活中重要的联系群体。

• 担任管理员的小组

除了5个邮件组的创建者外，小容还是7个邮件组的管理员之一。其实，每个邮件组都可以有多名创建者和管理员。 其中2个邮件组的成员超过300人以上，4个邮件组的成员在10人及10人以下。实际上， 成员少的4个邮件组基本上处于荒废的状态，而成员多的3个邮件组近期的交流也不是很活跃。

• 未担任管理员的小组

上面20个中，成员数量为238517和225386的2个邮件讨论组是关于Google产品的英文讨论组，所以成员数量显得特别奇怪。

后面两张图的表格中，第一列的数据为新贴子，第二列的数据为成员数量。