Best practices

This page explains best practices to follow when using Memorystore for Memcached.

Architect your application to handle cache misses

You should follow standard cache-design best practices by designing your cache to handle cache-misses and service unavailability. See the Service Level Agreement for information on Memorystore for Memcached's commitment to uptime.

Design your application so that cache misses and temporary service downtime do not stop your application from retrieving data from the underlying database which your Memcached instance supports.

Also, if you experience keyspace unavailability, wait and retry using exponential backoff. Make sure to set a time limit after which your retry strategy ceases.

Connecting to Memcached nodes

When querying Memcached nodes with commands like set, get, and delete, you should connect to the IP addresses of the nodes directly. It is possible to run these commands on the Auto Discovery endpoint, however this is not recommended because it causes reduced performance for your application.

We recommend that you use the Memorystore for Memcached Auto Discovery service. This service automates cluster IP address management when adding or removing nodes from your cluster. For instructions on setting up auto-discovery for your cluster, see Using the Auto Discovery Service.

Properly configuring the max-item-size parameter

This section explains how to best configure the max-item-size parameter. For steps on adjusting this configuration parameter, see Configuring Memcached instances. For the full list of available Memcached configuration parameters, see Memcached configurations.

Supported values and default values

For open source Memcached, the minimum value for max-item-size is 1KiB, the maximum value is 1 GiB, and the default value is 1 MiB. For Memorystore for Memcached the minimum value is 512 KiB, the maximum value is 128 MiB, and the default value is 1 MiB. Also, any value to which you set this configuration must be evenly divisible by 512 KiB.

Caching an entry larger than the configured max-item-size

When you attempt to cache an entry larger than the configured max-item-size, Memcached fails the operation and returns false. If possible, build logic into your application to surface this error from the Memcached OSS client so that you can debug it. Attempting to cache an entry larger than the configured max-item-size can cause high latency for your instance.

Setting max-item-size to maximum value

You can resolve some issues with the max-item-size parameter by setting it to the maximum value; however, this is not a good practice, so you should not use this strategy in production. Memcached memory management is based on slabs, and storing items that are larger than the slab leads to inefficient memory allocation.

Avoiding max-item-size configuration issues

First, figure out what maximum item size is required for your cache. Set max-item-size to be slightly larger than the biggest item size, as a safety margin.

Note that the size of values written to your cache may change in your application over time. Also, the cluster can be misconfigured (for example, when migrating from one environment to another). An additional measure you can take is to validate the maximum item size in your application, so that the request is rejected if your application tries to cache items larger than the configured setting.

How to balance an unbalanced Memcached cluster

How unbalanced clusters occur, and associated risks

In some rare circumstances, when you create a Memcached instance nodes can be unevenly distributed across zones in a region. This occurs when a zone is unavailable at that same time that you provision the cluster.

An unbalanced cluster increases the potential for data-loss because nodes are not as evenly distributed as they could be. The cluster does not automatically re-balance when the zone that was down comes back online.

How to rebalance your cluster

You can rebalance your cluster by temporarily increasing the number of nodes in your cluster, then scaling down the number of nodes to the original number of nodes. This scaling up and scaling down action allows the Memorystore for Memcached system to re-distribute the nodes evenly across available zones.

The success of this method for rebalancing your cluster depends upon the availability of the zones in question. Google Cloud does not currently list available/unavailable zones, so you can only tell if the zone is online if the nodes are correctly balanced during the scaling operation.

Cloud Monitoring best practices

In order to track the performance of your cache over time, you should use Cloud Monitoring to monitor some essential Memorystore for Memcached metrics:

  • Memory usage (memcache.googleapis.com/node/cache_memory)
  • CPU usage percent (memcache.googleapis.com/node/cpu/utilization)

Tracking these two metrics over time helps you determine how efficiently your cluster is being used, and whether you should consider increasing or decreasing the size of your cluster.

For example, if the metrics indicate that memory usage and cpu usage have grown over time to over 80%, it is possible that the trend may continue. As a result you may increase your instance size early so that your cache has space to store new values as your application's resource requirements increase.

We recommend that you set an alert for when your memory usage and CPU usage reach 80%.

Alternatively, tracking these metrics over time may indicate that you are not using all of the space and CPU resources you currently have. In this case it would be more cost effective to decrease the size of your cluster.

What's next