Declaración de derechos de autor: puede reimprimir cuando lo desee. Al reimprimir, asegúrese de indicar la fuente original y la información del autor del artículo y esta declaración de derechos de autor en forma de hipervínculo.
http://www.chedong.com/blog/archives/001431.html
Pruebe:
La opción de compresión MEMCACHE_COMPRESSED en la función PHPmemcache_set() está habilitada y memcache_get() puede descomprimir automáticamente el objeto de caché comprimido durante lecturas posteriores.
Efecto:
Después de las pruebas, para la aplicación actual de Blog Bus, después de habilitar la compresión, la cantidad de objetos almacenados en la misma capacidad (2G) se duplicó aproximadamente y la tasa de aciertos de la caché aumentó de aproximadamente el 50% a aproximadamente el 60%. Aún es necesaria una inversión en hardware para aumentar aún más la tasa de aciertos. Después de agregar 2 veces la memoria, la tasa de aciertos de la caché finalmente se incrementó al 90%.
Prerrequisito 0: la memoria caché es útil y vale la pena mejorar la tasa de aciertos;
Si vale la pena aumentar el rendimiento del 60% al 90% o del 90% al 95% depende de si la mejora del rendimiento después del impacto vale la pena
Premisa 1: MemCached está lleno Utilice la herramienta memcached para verificar las estadísticas de capacidad; memcached para ver si está lleno. No es que ya esté lleno. Si el espacio de MemCached no está lleno cuando se está ejecutando por completo, no tiene sentido habilitar la compresión. Además: si descubre que MemCached no está lleno, es mejor reducir la capacidad del MemCached correspondiente para liberar más memoria para otros; servicios para almacenar en caché;
Premisa 2: Relación de compresión Los datos almacenados en caché pueden tener más de unos pocos cientos de bytes. Si todos son pares clave-valor de menos de 100 bytes, la compresión en realidad puede causar expansión. Dado que el tamaño de los objetos de la caché se almacena en bloques de tamaño fijo en Memcached, el tamaño mínimo es 88 B. Por lo tanto, la compresión y expansión causada por datos demasiado pequeños no es un gran problema para
la pérdida de CPU de la aplicación front-end:
La pérdida de CPU por compresión adicional de datos es mucho menor que la mejora de rendimiento generada por el aumento en la tasa de aciertos de caché y la reducción del acceso a la base de datos en segundo plano. Es similar a la compresión gzip/deflate de http. Los datos comprimidos generalmente son aproximadamente el 30% de. el tamaño de los datos originales, el ahorro del 70% del consumo de rendimiento de la transmisión será mayor que la pérdida de rendimiento causada por la compresión del archivo;
la siguiente es la distribución del bloque de datos de un MemCached después de habilitar la compresión:
# Item_Size Edad_máx. 1 MB_páginas ¿Cuenta completa?
1 104 B 342694 s 60 604918 sí<==La distribución de mayoría mínima original parece estar un poco inflada en 88 B
2 136 B 344213 s 39 300690 sí
3 176 B 324647 s 145 863765 sí
4 224 B 347049 s 52 243412 sí
5 280 B 332911 s 47 175968 sí
6 352 B 257080 s 114 339491 sí
7 440 B 330976 s 39 92934 sí
8 552 B 310225 s 51 96849 sí
9 696 B 305251 s 68 102407 sí
10 872 B 298607 s 74 88947 sí
11 1,1 kB 276463 s 70 66919 sí
12 1,3 kB 279819 s 79 60198 sí
13 1,7 kB 293690 s 97 59073 sí
14 2,1 kB 304436 s 116 56492 sí
15 2,6 kB 298020 s 102 39576 sí
16 3,3 kB 324546 s 100 31000 sí
17 4,1 kB 321757 s 97 24056 sí
18 5,2 kB 320132 s 91 18018 sí
19 6,4 kB 332232 s 89 14062 sí
20 8,1 kB 330696 s 81 10287 sí
21 10,1 kB 329582 s 76 7676 sí
22 12,6 kB 337278 s 72 5832 sí
23 15,8 kB 348626 s 66 4224 sí
24 19,7 kB 345881 s 56 2856 sí
25 24,6 kB 345825 s 44 1804 sí
26 30,8 kB 333460 s 31 1023 sí
27 38,5 kB 335782 s 22 572 sí
28 48,1 kB 302109 s 17 357 sí
29 60,2 kB 358674 s 18 306 sí
30 75,2 kB 396573 s 17 221 sí
31 94,0 kB 431605 s 11 110 sí
32 117,5 kB 418652 s 7 56 sí
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 sí