Configuring Memcached in Magento 1.4

In the Magento 1.4 release, the memcached backend configuration has changed. There are now more options listed than in previous Magento versions. Some confusion has resulted in how to configure memcached in this new version as the previous configuration for memcached no longer works resulting in the Magento site failing to load if used. Documentation on this new configuration is scarce, so some research must be done to understand its implementation.

The new local.xml.additional memcached portion that comes standard in Magento now looks like this:

[code language=”xml”]



















[/code]

Magento now uses a two-level caching system for it’s configuration. Looking at the Zend online documentation, the two-level caching mechanism can be understood. It is explained here under the Zend_Cache_Backend_TwoLevels section:

“This (extend) backend is an hybrid one. It stores cache records in two other backends : a fast one (but limited) like Apc, Memcache… and a “slow” one like File, Sqlite…”

To get memcached up and working, this configuration can be used:

[code language=”xml”]
File
memcached



[ip_of_memcache_server]
11211
1

memcached



[ip_of_memcache_server]
11211
1



[/code]

This new configuration is similar to the old one with some changes. The option above is set to use files. This acts as a backup mechanism in the event that the primary memcached instance fails. In previous versions of Magento, there was no failover mechanism. If memcached were to die or stop responding, it would result in the entire Magento site to go down.

It is worth noting that the cache could also be set to use a memcached config, If this were the same ip and port of the configuration, the configuration will work but any failover would be negated as a memcached failure would still result in the site going down. As an option, a second memcached instance would be setup to listen on a different port than the default 11211 (or use a local unix socket). This would still allow the to perform “fast” as it is not dependent on file system access. Alternatively you could also use the /dev/shm memory based file system for the set to “file” so if the fast memcached backend failed you would still have faster failover to memory instead of disk.

To further decrease the chances that Magento would fail as result of a memcached failure, Magento does support multiple distributive memcached servers. You can run multiple memcached instances on the same server on different ports (or unix sockets) or if your store is running on multiple servers in a cluster environment, you can run a separate memcached instance on each server. In both of these cases, a single memcached failure will not result in the site going down. A distributive configuration can be placed with in the section and looks like the following:

[code language=”xml”]

[ip_of_memcache_server1]
11211
1


[ip_of_memcache_server2]
11211
1


[ip_of_memcache_server3]
11211
1

[/code]

Please remember to always follow good security practices and never run memcached on an external public ip address. Always run memcached on a local unix socket or localhost. If a clustered environment exists with a private internal network that is in no way accessible from the internet, memcached may be set to listen on those private interfaces.