API Memcache para servicios agrupados antiguos

En esta página se ofrece una descripción general del servicio de caché de memoria de App Engine. Las aplicaciones web escalables de alto rendimiento suelen usar una caché de datos distribuida en memoria delante o en lugar de un almacenamiento persistente robusto para algunas tareas. App Engine incluye un servicio de caché en memoria para este fin. Para saber cómo configurar, monitorizar y usar el servicio de Memcache, consulta el artículo Usar Memcache.

Cuándo usar una caché de memoria

Un uso de la memoria caché consiste en acelerar las consultas comunes del almacén de datos. Si muchas solicitudes hacen la misma consulta con los mismos parámetros y los cambios en los resultados no tienen que aparecer en el sitio web de inmediato, la aplicación puede almacenar en caché los resultados en memcache. Las solicitudes posteriores pueden comprobar la caché de memoria y solo realizar la consulta de Datastore si los resultados no están o han caducado. Los datos de sesión, las preferencias de los usuarios y otros datos devueltos por las consultas de páginas web son buenos candidatos para el almacenamiento en caché.

Memcache puede ser útil para otros valores temporales. Sin embargo, cuando te plantees almacenar un valor únicamente en la memoria caché y no en otro almacenamiento persistente, asegúrate de que tu aplicación se comporte de forma aceptable si el valor deja de estar disponible de repente. Los valores pueden caducar de la memoria caché en cualquier momento y pueden caducar antes de la fecha de vencimiento establecida para el valor. Por ejemplo, si la ausencia repentina de los datos de sesión de un usuario provocara un fallo en la sesión, esos datos probablemente deberían almacenarse en el almacén de datos además de en la caché de memoria.

Niveles de servicio

App Engine admite dos niveles del servicio Memcache:

  • Memcache compartida es la opción predeterminada gratuita para las aplicaciones de App Engine. Proporciona capacidad de caché según el mejor esfuerzo posible y está sujeta a la demanda general de todas las aplicaciones de App Engine que usen el servicio de Memcached compartido.

  • Memcache dedicada proporciona una capacidad de caché fija asignada exclusivamente a tu aplicación. Se factura por GB-hora de tamaño de caché y requiere que la facturación esté habilitada. Si controlas el tamaño de la caché, tu aplicación puede funcionar de forma más predecible y con menos lecturas del almacenamiento duradero, que es más caro.

Ambos niveles de servicio de memcache usan la misma API. Para configurar el servicio de Memcache de tu aplicación, consulta Usar Memcache.

En la siguiente tabla se resumen las diferencias entre las dos clases de servicio de memcache:

Función Memcache especializada Memcache compartida
Precio 0,06 USD por GB y hora Gratis
Capacidad
us-central
De 1 a 100 GB
asia-northeast1, europe-west, europe-west3 y us-east1:
De 1 a 20 GB
Otras regiones:
De 1 a 2 GB
Sin capacidad garantizada
Rendimiento Hasta 10.000 lecturas o 5000 escrituras (exclusivas) por segundo y por GB (elementos < 1 KB). Para obtener más información, consulta Estadísticas de la caché. No garantizado
Almacén duradero No No
Acuerdo de nivel de servicio Ninguno Ninguno

La facturación de memcache dedicada se cobra en incrementos de 15 minutos. Si pagas en una moneda que no sea el dólar estadounidense, se aplicarán los precios que figuran para tu divisa en la página de SKUs de Cloud Platform.

Si tu aplicación necesita más capacidad de memcache, ponte en contacto con nuestro equipo de Ventas.

Límites

Se aplican los siguientes límites al uso del servicio de memcache:

  • El tamaño máximo de un valor de datos almacenado en caché es de 1 MiB (2^20 bytes) menos el tamaño de la clave menos una sobrecarga que depende de la implementación, que es de aproximadamente 73 bytes.
  • Una clave no puede tener más de 250 bytes. En el tiempo de ejecución de PHP, si intentas definir memcache con una clave más larga, la llamada generará una excepción. (Otros tiempos de ejecución se comportan de forma diferente).
  • Las operaciones por lotes "multi" pueden tener cualquier número de elementos. El tamaño total de la llamada y el tamaño total de los datos obtenidos no deben superar los 32 megabytes.
  • Una clave de memcache no puede contener un byte nulo.

Recomendaciones y prácticas recomendadas

Cuando uses Memcache, te recomendamos que diseñes tus aplicaciones de la siguiente manera:

  • Gestiona el caso en el que un valor almacenado en caché no siempre esté disponible.

    • Memcache no es un almacenamiento duradero. Según la política de desalojo, las claves se desalojan cuando se llena la caché. Los cambios en la configuración de la caché o los eventos de mantenimiento del centro de datos también pueden vaciar parte o la totalidad de la caché.
    • Memcache puede no estar disponible temporalmente. Las operaciones de Memcache pueden fallar por varios motivos, como cambios en la configuración de la caché o eventos de mantenimiento del centro de datos. Las aplicaciones deben diseñarse para detectar operaciones fallidas sin exponer estos errores a los usuarios finales. Estas directrices se aplican especialmente a las operaciones de conjunto.
  • Utiliza la función de procesamiento por lotes de la API cuando sea posible.

    • De esta forma, se aumenta el rendimiento y la eficiencia de tu aplicación, sobre todo en el caso de los elementos pequeños.
  • Distribuye la carga en tu espacio de claves de memcache.

    • Si un solo elemento o un pequeño conjunto de elementos de memcache representa una cantidad desproporcionada de tráfico, se dificultará el escalado de tu aplicación. Estas directrices se aplican tanto a las operaciones por segundo como al ancho de banda. A menudo, puedes solucionar este problema fragmentando tus datos de forma explícita.

      Por ejemplo, puedes dividir un contador que se actualiza con frecuencia entre varias claves, leerlas y sumarlas solo cuando necesites un total. Del mismo modo, puedes dividir un fragmento de datos de 500 KB que se debe leer en cada solicitud HTTP en varias claves y volver a leerlos con una sola llamada a la API por lotes. Lo ideal sería almacenar en caché el valor en la memoria de la instancia. En el caso de memcache dedicado, la tasa de acceso máxima de una sola clave debe ser entre uno y dos órdenes de magnitud inferior a la valoración por GB.

  • Conserva tus propias claves para recuperar valores de la caché.

    • Memcache no proporciona un método para enumerar claves. Debido a la naturaleza de la caché, no es posible enumerar las claves sin interrumpirla. Además, algunos lenguajes, como Python, cifran claves largas y las claves originales solo las conoce la aplicación.

Implementación de memcache en PHP

App Engine incluye implementaciones de las APIs estándar Memcache y Memcached, que invocan el servicio Memcache de App Engine "bajo el capó". Algunas funciones se pueden invocar ("stubbed"), pero no hacen nada, ya que no son necesarias en el contexto de una aplicación de App Engine. Por lo tanto, se ignoran las llamadas a las siguientes funciones:

Funciones simuladas en la API de Memcache

  • memcache_add_server()
  • memcache_close()
  • memcache_connect()
  • memcache_pconnect()
  • memcache_set_compress_threshold()
  • addServer()
  • close()
  • connect()
  • pconnect()
  • setCompressThreshold()

Funciones simuladas en la API de Memcached

  • addServer()
  • addServers()
  • getAllKeys()
  • getServerByKey()
  • getServerList()
  • getStats()
  • getVersion()
  • isPersistent()
  • isPristine()
  • quit()
  • resetServerList()
  • setSaslAuthData()

Ejemplo de uso de la API de Memcache para PHP en App Engine:

$memcache = new Memcache;
return $memcache->get($key);

Ejemplo de uso de la API de PHP de Memcached en App Engine:

$memcache = new Memcached;
$memcache->set('who', $request->get('who'));
return $twig->render('memcache.html.twig', [
    'who' => $request->get('who'),
    'count' => $memcache->increment('count', 1, 0),
    'host' => $request->getHost(),
]);

Cómo caducan los datos almacenados en caché

Memcache contiene pares clave-valor. Los pares de la memoria cambian en cualquier momento a medida que se escriben y se recuperan elementos de la caché.

De forma predeterminada, los valores almacenados en el servicio Memcache se conservan el mayor tiempo posible. Los valores se pueden expulsar de la caché cuando se añade un valor nuevo a la caché y la caché tiene poca memoria. Cuando se expulsan valores debido a la presión de la memoria, se expulsan primero los valores que se hayan usado menos recientemente.

La aplicación puede proporcionar una hora de vencimiento cuando se almacena un valor, ya sea como un número de segundos relativo al momento en que se añade el valor o como una hora de época de Unix absoluta en el futuro (un número de segundos desde la medianoche del 1 de enero de 1970). El valor se expulsa a más tardar a esta hora, aunque se puede expulsar antes por otros motivos. Si incrementas el valor almacenado de una clave, no se actualizará su tiempo de vencimiento.

En raras ocasiones, los valores también pueden desaparecer de la caché antes de que caduquen por motivos distintos a la presión de memoria. Aunque Memcache es resistente a los fallos del servidor, los valores de Memcache no se guardan en el disco, por lo que un fallo del servicio puede provocar que los valores no estén disponibles.

Por lo general, una aplicación no debe esperar que un valor almacenado en caché esté siempre disponible.

Puedes borrar toda la caché de una aplicación a través de la API o en la sección de caché de memoria de la consola deGoogle Cloud .

Estadísticas de la caché

Operaciones por segundo por tamaño de elemento

Memcache dedicado se valora en operaciones por segundo por GB, donde una operación se define como un acceso individual a un elemento de caché, como get, set o delete. La tasa de operaciones varía en función del tamaño del elemento, aproximadamente según la siguiente tabla. Si se superan estas valoraciones, puede que aumente la latencia de la API o que se produzcan errores.

En las siguientes tablas se indica el número máximo de operaciones exclusivas get-hit o set sostenidas por GB de caché. Tenga en cuenta que una operación get-hit es una llamada get que busca si hay un valor almacenado con la clave especificada y devuelve ese valor.

Tamaño del elemento (KB) Máximo de get-hit operaciones/s Máximo de set operaciones/s
≤1 10.000 5000
100 2000 1000
512 500 250

En teoría, una aplicación configurada para tener varios GB de caché puede alcanzar una tasa de operaciones agregada que se calcula multiplicando el número de GB por la tasa por GB. Por ejemplo, una aplicación configurada para 5 GB de caché podría alcanzar las 50.000 operaciones de memcache por segundo en elementos de 1 KB. Para alcanzar este nivel, es necesario que la carga se distribuya correctamente en el espacio de claves de memcache.

En cada patrón de E/S, los límites indicados arriba se aplican a las lecturas o a las escrituras. En el caso de las lecturas y escrituras simultáneas, los límites se aplican en una escala variable. Cuantas más lecturas se realicen, menos escrituras se podrán llevar a cabo y viceversa. A continuación, se muestran ejemplos de límites de IOPS para lecturas y escrituras simultáneas de valores de 1 KB por cada 1 GB de caché:

IOPS de lectura IOPS de escritura
10000 0
8000 1000
5000 2500
1000 4500
0 5000

Unidades de procesamiento de Memcache (MCU)

El rendimiento de Memcache puede variar en función del tamaño del elemento al que acceda y de la operación que quiera realizar en él. Puedes asociar aproximadamente un coste a las operaciones y estimar la capacidad de tráfico que puedes esperar de memcache dedicado mediante una unidad llamada unidad de computación de Memcache (MCU). La MCU se define de forma que puedes esperar 10.000 MCUs por segundo por cada GB de memcache dedicado. La Google Cloud consola muestra cuántas MCUs está usando tu aplicación.

Ten en cuenta que la MCU es una estimación estadística aproximada y no es una unidad lineal. Cada operación de caché que lee o escribe un valor tiene un coste de MCUs correspondiente que depende del tamaño del valor. El coste de la MCU de un set depende del tamaño del valor: es el doble del coste de una operación get-hit correcta.

Tamaño del elemento de valor (KB) Coste de MCUs de get-hit Coste de MCUs de set
≤1 1.0 2,0
2 1.3 2.6
10 1,7 3.4
100 5,0 10,0
512 20,0 40,0
1024 50,0 100,0

Las operaciones que no leen ni escriben un valor tienen un coste de MCUs fijo:

Operación MCU
get-miss 1.0
delete 2,0
increment 2,0
flush 100,0
stats 100,0

Ten en cuenta que una operación get-miss es una get que determina que no hay ningún valor almacenado con la clave especificada.

Siguientes pasos

  • Consulta cómo configurar, monitorizar y usar Memcache en Usar Memcache.