版權聲明：可任意轉載，轉載時請務必以超連結形式標明文章原始出處及作者資訊及本版權聲明。
http://www.chedong.com/blog/archives/001431.html
試試看：
啟用了PHPmemcache_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 %的傳輸效能消耗所得會大於檔案壓縮所帶來的效能損耗；
以下是啟用壓縮後的一個MemCached的資料區塊分佈：
# Item_Size Max_age 1MB_pages Count Full?
1 104 B 342694 s 60 604918 yes<==原先最小大部分分佈在88 B看來還是有些膨脹的
2 136 B 344213 s 39 300690 yes
3 176 B 324647 s 145 863765 yes
4 224 B 347049 s 52 243412 yes
5 280 B 332911 s 47 175968 yes
6 352 B 257080 s 114 339491 yes
7 440 B 330976 s 39 92934 yes
8 552 B 310225 s 51 96849 yes
9 696 B 305251 s 68 102407 yes
10 872 B 298607 s 74 88947 yes
11 1.1 kB 276463 s 70 66919 yes
12 1.3 kB 279819 s 79 60198 yes
13 1.7 kB 293690 s 97 59073 yes
14 2.1 kB 304436 s 116 56492 yes
15 2.6 kB 298020 s 102 39576 yes
16 3.3 kB 324546 s 100 31000 yes
17 4.1 kB 321757 s 97 24056 yes
18 5.2 kB 320132 s 91 18018 yes
19 6.4 kB 332232 s 89 14062 yes
20 8.1 kB 330696 s 81 10287 yes
21 10.1 kB 329582 s 76 7676 yes
22 12.6 kB 337278 s 72 5832 yes
23 15.8 kB 348626 s 66 4224 yes
24 19.7 kB 345881 s 56 2856 yes
25 24.6 kB 345825 s 44 1804 yes
26 30.8 kB 333460 s 31 1023 yes
27 38.5 kB 335782 s 22 572 yes
28 48.1 kB 302109 s 17 357 yes
29 60.2 kB 358674 s 18 306 yes
30 75.2 kB 396573 s 17 221 yes
31 94.0 kB 431605 s 11 110 yes
32 117.5 kB 418652 s 7 56 yes
33 146.9 kB 408422 s 3 17 no
34 183.6 kB 277529 s 2 7 no
35 229.5 kB 139156 s 1 3 no
36 286.9 kB 232221 s 1 1 no
37 358.6 kB 1059 s 3 6 yes