memcache item

wstlwl

　　最近一直在捣腾memcached的优化问题，由于我们的memcached上的比较匆忙，导致实际中只有67%的命中率，实在不理想，用memcached-tool工具查看，有几个slabs居然还没有满，但是最近我们放数据进去时过一会就get misses了。显然，这个问题是由于我们之前上memcached的时候没有预先评估存入的items的长度，启动服务器时没有有效调整slabs的增长因子导致的。于是，首先，我就决定看下memcachd服务断源码，看看服务器端是怎么算这个items的长度的。下面是主要的源代码(Version1.3.X):
　　static size_t item_make_header(const uint8_t nkey, const int flags, const int nbytes,  00081 char *suffix, uint8_t *nsuffix)
　　{
　　*nsuffix = (uint8_t ) snprintf(suffix, 40, " %d %d\r\n" , flags, nbytes - 2);
　　return sizeof (item ) + nkey + *nsuffix + nbytes;
　　}
　　其中nkey表示items的键长，*nsuffix表示items的后缀长度，nbytes表示items中value的长度，至于size(item)这个的长度在32位机中为32，在64位机中为48。实际使用中由于每个键值的后面要加上'\0'作为结尾，value后面要加上'\r\n'结尾，那么最后的结果要加上3个字节。下面举出一些具体的测试列子(java 客户端，键值统一为："DM_20100419")：
　　(1)、byte=1。set DM_20100419 1 0 1。按照上面的规则计算公式为32+(11+1)+6+(1+2)=53。
　　(2)、创建一个对象(一定要实现序列化接口)，set DM_20100419 8 0 43。同样，按照上面的规则得到计算结果为：32+(11+1)+7+(43+2)=96.
　　(3)、double=1。 set DM_20100419 512 0 8。按照规则计算32+(11+1)+8+(8+2)=62.
　　经过服务器端验证均与上述计算结果吻合。谨以此与大家分享，希望能够给大家一点帮助。