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代码优化要方便得多。