Friday, December 18, 2009

PHP Memcache Extension - Lesser Known Pitfalls

Ah yes, we love memcache, sometimes it even makes me wonder, why did I spend so much time on optimizing queries on large db tables when I can just cache them in memory. Some people even take memcache into its extreme by utilizing it as session and data storage (depending on the situation and sensitivity of the data, it's really not a good idea, but i'll save this as another topic for another day)

Now, back to the main topic. There are a few less known pitfalls about memcache. If you've been lucky so far, you probably never experienced it, but if on the other hand, you are like me, then you should pay attention. I'm going to break it down into a couple sections to discuss the pitfall.

Pitfall #1: serialized data
The fundamental.
Memcache stores data in key-value pair in the memory for faster data retrieval. It relies on serializing data to maintain stored data and its structures.

The pitfall.
Did you catch the word "serializing" in the last paragraph? If not, read it again out loud. Yes, memcache relies on serializing data. In another word, it relies on data that can be serialized. Normally, when there's an error in setting values into memcache (like memory is full), memcache will fail silently. However, if the data you passed in is not serializable, memache will throw an error. Why? because memcache wouldn't know what to do with the data.
For int, float, or bool, memacache will first convert the value into a string then store it. In return, when you try to get the data, a string is returned instead of the original type.


The solution.

Oh yeah, pitfall!=total failure. There's always a solution (or workaround if you must) out there. The simplest thing to do is to just serialize the data before it is passed to memcache. The Memcache::set()'s third argument $flag supports an undocumented value "1". If you pass in 1, it essentially tells memcache to deserialize the data it received.
Example:  $memcache->set($key, serialize($var), 1)
Also, make sure that once you have set a key to use the secret flag, the next time you set a value to it, maintain the flag or the server will be marked as failed.

Pitfall #2: memcache fail silently on failed compression
The fundamental. From the documentation of Memcache::set()
"Use MEMCACHE_COMPRESSED to store the item compressed (uses zlib)."

The pitfall. Again, there's a word to catch in the last paragraph. This time, it's "zlib". So what will happen if zlib is not installed? Well, nothing will be put into memcache if you always pass in the compression flag. However, since memcache most times fails silently (except the pitfall #1), you probably won't realize the issue until your main database is killed.

The solution. Simple: INSTALL ZLIB.

I'm sure there are many other pitfalls out there. If I see it, i'll definitely put it up again (hopefully i will find those pitfalls out without a total server failure).

5 comments:

  1. "Some people even take memcache into its extreme by utilizing it as session and data storage (That's WRONG WRONG WRONG, but i'll save this as another topic for another day)"

    Ok...

    So why is it "WRONG WRONG WRONG" to use memcache for sessions?

    ReplyDelete
  2. that was some strong statements I made when I was writing that post. Thank you for pointing that out. :) I have changed the wording a bit to not deny the all usages of memcache in replacement of session.

    Here's a couple situations I think are not good ideas:
    1. putting shopping cart data in memcache on a high volume e-commerce site. if the memory on the memcache server runs out or it crashes, your customers will instantly loose everything in the cart.
    2. putting user session data in memcache. this one is arguable. again, in a high volume situation, if memcache server goes away, just imagine how many queries will be triggered on your database.

    I'm sure it's very arguable that none of those will be problems when using clustered memcache servers and have memcache servers installed with 64GB of memories (God forbid if all 64GB of data all got lost because of a power outage)

    ReplyDelete
    Replies
    1. Wow! At last I got a webpage from where I know how to truly take helpful information concerning my study and knowledge.
      Web development Company

      Delete
  3. his blog is so nice to me. I will keep on coming here again and again. Visit my link as well.bulk sms service

    ReplyDelete
  4. That is a owsome point in order to thank you an individual you've submitted a owsome technique of thanking an individual i like your current post in addition to i demand someone to keep discussing just like most of these content.Nimble Messaging Services

    ReplyDelete