I have been using memcached for a number of years now, and been amused by the many times that people new to memcached ask "How do I view the list of keys stored in memcached".
There is a perfectly valid reason why you should not want to view the list of keys stored in memcached. If your process requires functionality like that, then likely you are using memcached in a way that it wasn't designed to be used, or have some flaws in the design of your application. That being said, there are some advantages, when developing, to be able to view what is in the cache. It would be nice to start a fresh cache, do some operation, and then look at the contents of the cache to see if everything went in correctly. I've even built unit tests that check the contents of a cached entry to ensure that the code itself has succeeded. I also thought that it would be nice to have something where I can view cached entries, and even do commands on those cached entries (or even add new entries), to check certain functionality in applications that get data from the cache. To take it a step further, for ease of debugging, I thought it would be wonderful to have a watch-list of cache items, so that I can test a piece of code, and then at a glance at the contents of a number of keys. To that end, I have built onto memcached a web-based debugging console, which I call the webconsole. It uses the libevent queue that is already central to memcached, but provides a non-intrusive layer that provides some interaction with the running memcached instance. I did most of the coding last weekend, and twiddled with it a bit during the week on the train, but will be finishing it up this weekend. I have a half-completed version running at http://static.rhokz.com:8080/ When you hit that URL, you are actually hitting a mini-webserver running inside memcached (of sorts). The command line I used to start it is: ./memcached -d -u memcached -w 8080 That server is running in the UK, and so keep in mind that there is a little bit of latency that you wouldn't normally have when hitting it over a LAN, or something a bit closer (I'm actually in Australia, so its noticeable for me). Have a look at what I have up there and see if you feel it might be useful. I haven't finished the 'watch-list' part, but basically it will use cookies to store different sets of keys that you want to watch, and you can open and close those different sets, it would then show those keys, and their values, and change their colors when they are changed, gradually fading back to white after time (the longer it has been since it was changed), and so on. All information is stored in the browser itself, and no session information is kept in memcached. This means that the browser itself is responsible for maintaining the watch-list. This is not very finished, but I thought I would make it available now, to hear any feedback about it. The Lookup tab works, but not very integrated with other parts. The Watch tab is incomplete and not included in the running demo. The List tab works, but is very basic, and currently you have to reload the page in your browser to refresh it. The Commands tab, set is the only command I have really implemented so far. The Stats tab does nothing at the moment, but I expect it will have all the usual stats info. Later today, I will be forking Dustin's latest branch on github and putting the code up there. Even though this is for debugging, the code is very benign and would not impact a production instance if the '-w' option is not used (therefore not activating the webconsole). Even if webconsole is active it should not affect a production environment much if it is not being used. I have not yet made sure it is safe for mutli-threads, since I was using it single-threaded, I will add that in this weekend also. On a technical note, when you hit that URL, the entire front-end code (javascript, html and css) is provided in a single page, and all interaction from that point is done through ajax. This has a side benefit in that when you have webconsole running (by adding -w <port> to the command line) you end up with an http interface that returns data in XML. Including a list of all current keys, the ability to do a set using a http request. Effectively this has probably become another memcached protocol (when complete). For example, you could get a list of all keys in this test instance by hitting http://static.rhokz.com:8080/list or set a key with: http://static.rhokz.com:8080/set?key=something&value=value Feel free to play around with the test s Looking forward to hearing your ideas and comments. -- "Be excellent to each other"
