[bmatheny]

Since I wrote memkeys, maybe I can clarify a few things.

First, dropping packets matters. If you see only 30-40% of your traffic you can't guarantee that you have enough data to know what your hot keys actually are. This is especially true when you are interested in (for instance) sorting keys by bandwidth usage. You might have a key that gets half as many hits as the hottest key but is 4x the size and causing network link saturation. In this case, depending on how much data you're able to capture, you may or may not even see this data point. Also, the follow-up comment from corresation about patching memcache doesn't make sense to me.

Second, this was no 'jab' at etsy. I know the etsy guys incredibly well and we're all friends. We've collaborated on work in more than one occasion. The jab comment seems like unnecessary speculation. The comment about seeing how memkeys affects performance is of course spot on. In this case, one thread will peg a CPU core for packet capture but besides that will not be CPU intensive. Since it uses packet capture, memkeys doesn't actually interact with memcached directly so the impact should be minimal. We used it at Tumblr.

Third, fixing the packet loss issue in mctop wasn't feasible as the problem is with ruby-pcap not with mctop. Additionally, while Tumblr has plenty of ruby code in production we don't generally use it for building 'real-time' applications. There are better languages for the job.

I built memkeys because it solved a problem we had, and was fun. That's it.