Home >Backend Development >PHP Tutorial >Enable MEMCACHE_COMPRESSED compression and 'expand' MemCached_PHP tutorial
Copyright Statement: You can reprint it at will. When reprinting, please be sure to indicate the original source and author information of the article and this copyright statement in the form of a hyperlink. Try: Effect: Premise 0: The memory cache is useful, and the hit rate is worth improving; Premise 1: MemCached is full Premise 2: Compression rate CPU consumption of front-end applications: The following is the data block distribution of a MemCached after compression is enabled:
http://www.chedong.com/blog/archives/001431.html
Enable the MEMCACHE_COMPRESSED compression option in the PHPmemcache_set() function, and memcache_get() can automatically decompress the compressed cache object during subsequent reads.
After testing, for the current application of Blog Bus, after enabling compression, the number of objects stored in the same capacity (2G) has been doubled, and the cache hit rate has increased from about 50% to about 50%. To about 60%. Hardware investment is still necessary to further improve the hit rate. After increasing the memory by 2 times, the cache hit rate was finally increased to 90%;
Increase it from 60% to 90%, or from 90% to 95%, it depends on whether the performance improvement after the hit is worth it;
First use memcached-tool to check the capacity statistics of memcached to see if memcached is full. If the space of MemCached is not full when it is fully running, it is meaningless to enable compression; Moreover: if you find that MemCached is not full, it is best to reduce the corresponding capacity of MemCached to free up more memory for other services to cache;
The cached data is indeed larger than a few hundred bytes. If all key-value pairs are less than 100 bytes, compression may actually cause expansion. Since the size of cache objects is stored in fixed-size blocks in Memcached, the minimum size is 88 B. Therefore, the compression and expansion caused by too small data is not a big problem;
The CPU consumption of additional compression of data is far lower than the performance improvement brought by the increase in cache hit rate and the reduction of background database access. It is similar to the gzip/deflate compression of http. The compressed data is generally It is about 30% of the original data size, saving 70% of the transmission performance consumption and the gain will be greater than the performance loss caused by file compression;
# Item_Size Max_age 1MB_pages Count Full?
1 104 B 342694 s 60 604918 yes<==The original minimum majority distribution seems to be a bit bloated at 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 25708 0 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