I'm trying to understand the need for this change. I'm guessing that something like this happened:

• You are storing something big, like complete HTML pages, in memcached
• You hit the 1 MB limit on cached values
• You tried compression to get below the limit, but it didn't completely fix the problem,
• You want to know how close to 1 MB you are with compression.

Is this accurate, or did you have another need for this change?

Nope that was it, we were getting a lot of errors and couldn't pinpoint why. Adding this to the logs allowed us to know which keys were too big.

I'm actually fine with closing this PR as we actually swapped to pymemcache for other reasons and our in-house django wrapper for it just rejects objects over 1MB after compressed.

I like the idea of the commit, since the 1 MB limit is not commonly known, and serialization + compression makes it hard to see exactly when it happens. I'd prefer that pylibmc raises a more specific error that includes the size of the serialized value. It looks like a libmemcached change might be making this harder than it seems.

Right... until I added this for our fork we were getting a plethora of timeouts caused by sending super large values to memcached. We had no way of knowing, but it turned out our blog posts were attempting to cache 6MB of compressed data because the pickle call was invoking all() on a django model. Adding this helped better identify what was causing problems.

lericson/pylibmc#184 has been fixed with a code change, so there may be some more options here.