Xaprb

Ryan posted an article on the MySQL Performance Blog about how to use mk-query-digest to analyze and understand your memcached usage with the same techniques you use for MySQL query analysis. This is an idea that came to me during the 2009 MySQL Conference, while talking to our friends from Schooner, who sell a memcached appliance.

It suddenly struck me that the science of memcached performance is basically nonexistent, from the standpoint of developers and architects. Everyone treats it as a magical tool that just performs well and doesn’t need to be analyzed, which is demonstrably and self-evidently false. memcached itself is very fast, true, so it doesn’t usually become a performance bottleneck the way a database server does. But that’s not the point. There is a lot to win or lose in the way you use it, which can heavily influence your application’s performance. That’s what the new features in mk-query-digest are designed to analyze.

Here’s an example of the types of problems we’ve seen in production memcached usage, which are very hard to catch without a good tool. What if a “global” value is accidentally stored with a key that includes the user ID? This will cause the value to be duplicated again and again for every user, instead of being stored once. There are really only two ways to catch this: 1) know the application’s source code inside and out, and 2) analyze the memcached traffic scientifically. (Even if you know the source code well, there’s a good chance you can miss a bug like this.) I could go on listing the types of problems you can inadvertently create with a key-value database, but I’ll leave it at that.

The features are only available in trunk, and will be released with this month’s scheduled release.

If you don’t like DRM (Digital Restrictions Management), there are lots of ways to protest it. One of the simplest and most effective is to pick a massively popular DRM’ed device, and express your dismay to the manufacturer and users. Here’s an idea:

1. Browse to the DRM-laden Amazon Kindle’s product page.
2. Look for reviews that mention the problems with its DRM.
3. Mark them as helpful.

Here is a selection of such reviews, in which the reviewers rightly protest the restrictions, even though some of them are not really educated about DRM per se:

Having invested HEAVILY in Amazon Kindle content, I looked forward to the new and improved version… I have a tremendous volume of Kindle content (public domain and Amazon). I discovered that I could not directly transfer from my computer backup for Kindle 1 to the new K2 (why my backup is on the computer is addressed later in this review). All my content had to be reformatted by Amazon and re-downloaded from their site specifically for and to the Kindle 2… All of my previous issues of magazines and newspapers were lost

Another one:

after 13 months the screen on my Kindle simply died.. when I spoke with Amazon customer service they confirmed that it’s a fairly common complaint… there is nothing I can do other than buy a new one… there are books that I have purchased that I now can’t read, and Amazon won’t even refund me my money for those!

This person is pretty clear on what’s wrong, even if he/she doesn’t call it DRM:

If your Kindle 1 breaks or you purchase a Kindle 2 all your Newspaper and Magazine issues will be UNREADABLE on the replacement or new device… Think about this for a moment. You BUY these periodicals and obtain the rights for your use, but if you purchase or replace your Kindle you have no further rights to read past issues YOU bought and paid for. .

Even people who are giving it 5 stars are noticing:

…e) Not allowing to display normal PDF documents unless sent to Amazon for turning it into Kindle format.

Cruising through my blog reader today, and came upon this blog post from Zmanda:

Our price increased today. Now we are one-tenth the cost of Symantec.

That is absolute genius. It is impossible to ignore, and will probably be remembered longer than almost anything else they could have written.