Memcache::set

Description

Memcache::set() stores an item
var with key on the
memcached server. Parameter expire is expiration
time in seconds. If it's 0, the item never expires (but memcached server
doesn't guarantee this item to be stored all the time, it could be deleted
from the cache to make place for other items).
You can use MEMCACHE_COMPRESSED constant as
flag value if you want to use on-the-fly
compression (uses zlib).

Note:

Remember that resource variables (i.e. file and connection descriptors)
cannot be stored in the cache, because they cannot be adequately
represented in serialized state.

Also you can use memcache_set() function.

Parameters

key

The key that will be associated with the item.

var

The variable to store. Strings and integers are stored as is, other
types are stored serialized.

flag

Use MEMCACHE_COMPRESSED to store the item
compressed (uses zlib).

expire

Expiration time of the item. If it's equal to zero, the item will never
expire. You can also use Unix timestamp or a number of seconds starting
from current time, but in the latter case the number of seconds may not
exceed 2592000 (30 days).

See Also

User Contributed Notes 9 notes

This is just two minor things about memcache that might not be perfectly clear, the limits on key and data sizes and what happen to flags in the memcache protocol.

* There is a max key size of 250 anything bigger gets truncated. There is also a (1MB - 42 bytes) limit on the data.

* In the memcache protocol there is a 16bit, 32bit in newer version, flag that you can set to whatever you want because memcache doesn't do anything with the flags. The php api doesn't let you get the flags because php uses the flags for php's own use such as "MEMCACHE_COMPRESSED" and I decided to test if it was doing something because it wasn't part of the memcache protocol.

Using set more than once for the same key seems to have unexpected results - it does not behave as a "replace," but instead seems to "set" more than one value for the same key. "get" may return any of the values.

This was tested on a multiple-server setup - behaviour may be different if you only have one server.

If you're interested in using compression, please note that, at least for PHP version 5.3.2 and Memcache version 3.0.4, when retrieving a key who's value is a numeric or boolean type, PHP throws a notice of the following:

Message: MemcachePool::get(): Failed to uncompress data

The way around this is to test your variable type before setting or adding it to Memcache, or even cast it as a string.

max amount of data: almost unlimited as long as your server can bear it.

speed and pace: well, thats another thing. We had a couple of data records which for application reasons must be kept in memory. Since the bunch of data is big and doesn't change very often, we considered caching it to memcache instead of retrieving it from the DB each and every time.

This isn't a general advice nor any quality statement, but we did a couple of tests with serialized arrays (50 MB), compressed and uncompressed and it turned out that in our particular scenario, memcache is much slower than the DB (mySql).

In general, one can not predict on the behavior of memcache in certain scenarios but always need to make some testing and benchmarking upfront before starting to deploy things to a live system.

Despite of the tests above, we are still using memcache for session caching instead of file system, since there are certain other things to consider and the amount of data is always small (few KB)