memcached使用与优化
1、客户端在与 memcached 服务建立连接之后，进行存取对象的操作,每个被存取的对象都有一个唯一的标识符 key，存取操作均通过这个 key 进行，保存到 memcached 中的对象实际上是放置内存中的，并不是保存在 cache 文件中的，这也是为什么 memcached 能够如此高效快速的原因。注意，这些对象并不是持久的，服务停止之后，里边的数据就会丢失。
2、当存入cached的数据超过了cached的容量后会将最长时间没调用的对象挤出，这正好应征了cached的特征。
3、利用memcached常用的做法：在每取得一次cached对象后，重新设置这个对象的cache时间，这样能够使得经常被调用的对象可以长期滞留在缓存中，使得效率增倍。
?
memcached 技术配置参数研究
failover表示对于服务器出现问题时的自动修复。
initConn初始的时候连接数，
minConn表示最小闲置连接数，
maxConn最大连接数，
maintSleep表示是否需要延时结束
nagle是TCP对于socket创建的算法，
socketTO是socket连接超时时间，
aliveCheck表示心跳检查，确定服务器的状态。
Servers是memcached服务端开的地址和ip列表字符串，
weights是上面服务器的权重，必须数量一致，否则权重无效
可从以下几方面考虑优化
1. 重新设置配置参数。
2. 尽量使用小容量的数据内容.
3. 增加memcached提高服务获取的内存总量、提高命中率。
4. 可以采用多个memcache服务进行侦听,分开处理,针对服务提供的频繁度划分服务内存
5. 根据服务器的性能不同设置权重 weights
6. 对需要使用memcache服务的机器ip,服务端做访问限制。
避免memcached里的数据不会被别有心意的人再利用，或责保证服务器的内存不被漫天遍地的垃圾数据所堆积,造成命中极低
7. 优化memcached客户端的代码。
1. synchronized 的问题
java memcached client源文件的大量方法里面都直接使用 synchronized 如 getConnection(), checkin() 等，而SockIOPool类似一个Singleton, 因此造成多线程失去了意义。同时 synchronized 方法里面又大量使用了 Hashtable 等synchronized保护的集合类。
2. InputStream 不优化的用法：
未加Buffer
private DataInputStream in = new DataInputStream( sock.getInputStream() );
一次读一字节
while (in.read(b, 0, 1) != -1)...
虽然说局域网的网速不存在问题，但是这样操作的话速度可想而知。
#59.151.6.168:11213 Field?????? Value
?????????????????? bytes?? 965623799
????????????? bytes_read 22404152833
?????????? bytes_written 238164862015
???????????????? cmd_get?? 212516055
???????????????? cmd_set??? 74288082
?? connection_structures??????? 1351
??????? curr_connections???????? 316
????????????? curr_items???? 4943569
?????????????? evictions?????? 49964
??????????????? get_hits?? 102206841
????????????? get_misses?? 110309214
????????? limit_maxbytes? 1073741824
???????????????????? pid??????? 3825
??????????? pointer_size????????? 32
?????????? rusage_system 358294.510000
???????????? rusage_user 16239.670000
???????????????? threads?????????? 1
??????????????????? time? 1209023021
?????? total_connections????? 135815
???????????? total_items??? 74288082
????????????????? uptime??? 20711187
???????????????? version?????? 1.2.2
0.48
179==2008.05.04 统计
stats
STAT pid 4355
STAT uptime 5004865
STAT time 1209866040
STAT version 1.2.2
STAT pointer_size 32
STAT rusage_user 197.590000
STAT rusage_system 587.010000
STAT curr_items 741989
STAT total_items 3158492
STAT bytes 922004468
STAT curr_connections 20
STAT total_connections 1380
STAT connection_structures 52
STAT cmd_get 3239347
STAT cmd_set 3158492
STAT get_hits 1765546
STAT get_misses 1473801
STAT evictions 1
STAT bytes_read 3731783494
STAT bytes_written 2126404906
STAT limit_maxbytes 1073741824
STAT threads 1
END
0.54
memcached 1.2.0
-p <num>??????????? port number to listen on
-s <file>?????????????? unix socket path to listen on (disables network support)
-l <ip_addr>??????? interface to listen on, default is INDRR_ANY
-d????????????????????????? run as a daemon
-r?????????????????????????? maximize core file limit
-u <username> assume identity of <username> (only when run as root)
-m <num>????????? max memory to use for items in megabytes, default is 64 MB
-M???????????????????????? return error on memory exhausted (rather than removing items)
-c <num>??????????? max simultaneous connections, default is 1024
-k????????????????????????? lock down all paged memory
-v????????????????????????? verbose (print errors/warnings while in event loop)
-vv??????????????????????? very verbose (also print client commands/reponses)
-h???????????????????????? print this help and exit
-i????????????????????????? print memcached and libevent license
-b???????????????????????? run a managed instanced (mnemonic: buckets)
-P <file>???????????? save PID in <file>, only used with -d option
-f <factor>????????? chunk size growth factor, default 1.25? growth factor //chunk 块 增长系数
-n <bytes>???????? minimum space allocated for key+value+flags, default 48
????????????????????????????????? 分配
尝试：
启用了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%的传输性能消耗所得会大于文件压缩带来的性能损耗；
#? Item_Size?? Max_age? 1MB_pages Count?? Full?
? 3???? 128 B?? 535047 s?????? 1?????? 2????? no
? 4???? 160 B? 19734117 s???? 196 1284388???? yes
? 5???? 200 B? 2753659 s???? 401 2102042???? yes
? 6???? 252 B? 1135150 s???? 321 1335680???? yes
? 7???? 316 B? 7923261 s?????? 1??? 3318???? yes
? 8???? 396 B? 9449969 s?????? 1??? 2647???? yes
? 9???? 496 B? 20639438 s???? 101? 213502???? yes
?10???? 620 B? 20704497 s?????? 1???? 509????? no
?11???? 776 B? 20711541 s?????? 1???? 838????? no
?12???? 972 B? 20608682 s?????? 1???? 642????? no
?13???? 1.2 kB 15213297 s?????? 1?????? 7????? no
Item_Size是我们储蓄实体大小的范畴
Max_age是所有实体存活的时间集合，单位是秒
Count是实体数目
1MB_pages？
?Full?是存贮空间满了没？
HTTP压缩对于纯文本内容可压缩至原大小的40％一下，从而提供60％以上的数据传输节约，虽然WEB服务器会因为压缩导致CPU占用的略微上升，但是可以节约大量用于传输的网络IO。对于数据压缩带来的用户浏览速度提升（让页面符合8秒定律），这点总体负载5%-10%上升是非常值得的。毕竟通过数据压缩会比通过不规范的HTML代码优化要方便得多。
?
1 楼 robbin 2008-12-26 你是blogbus的程序员？这是你的原创？ 2 楼 roger 2008-12-30 maintSleep表示是否需要延时结束