Memcache-top - perl command-line memcached stat reporter, top-like output(code.google.com)
code.google.com
Memcache-top - perl command-line memcached stat reporter, top-like output
http://code.google.com/p/memcache-top/
4 comments
I am not familiar with memcached and my knowledge about memcached is limited to Wikipedia. Having said that, is it fair to say that if you use SSD instead of HDD, you don't need memcached for improved performance?
Not exactly. There are a few things about memcached:
a) It's a database.
b) It's fast.
c) It forces you to use decent architecture.
a) Some types of data are stored only in memcached. For example user http sessions. There are also some other information that are stored only-in-memcached, like statistics. If memcached goes down, nobody will cry. Is it the same as normal database on HDD? No. It's because records are automatically dropped after a timeout. Can you emulate this behaviour in normal DB? Yes. By periodically going through DB and removing old sessions.
b) It's really fast. You can forget about optimizing your SQL queries, you can forget about slow ORM mappings. It takes a lot of pain from you.
c) Memcached nodes doesn't grow - you can't just add more ram, you have to kill machine and destroy memcached instance before. So you have to use reasonable architecture - shared nothing on the backend side, and consistent hashing on memcached side. When a programmer understands that data shouldn't be handled on one DB box, but should be partition on many memcached nodes - it changes the way of thinking. It's a big switch, like between desktop applications - with db tied to specific app, and cloud - with db that belongs to other parts of infrastructure.
a) Some types of data are stored only in memcached. For example user http sessions. There are also some other information that are stored only-in-memcached, like statistics. If memcached goes down, nobody will cry. Is it the same as normal database on HDD? No. It's because records are automatically dropped after a timeout. Can you emulate this behaviour in normal DB? Yes. By periodically going through DB and removing old sessions.
b) It's really fast. You can forget about optimizing your SQL queries, you can forget about slow ORM mappings. It takes a lot of pain from you.
c) Memcached nodes doesn't grow - you can't just add more ram, you have to kill machine and destroy memcached instance before. So you have to use reasonable architecture - shared nothing on the backend side, and consistent hashing on memcached side. When a programmer understands that data shouldn't be handled on one DB box, but should be partition on many memcached nodes - it changes the way of thinking. It's a big switch, like between desktop applications - with db tied to specific app, and cloud - with db that belongs to other parts of infrastructure.
Thanks for the excellent explanation.
In Rails we just have a page that prints out CACHE.stats.
Amnesia is kinda slick, and works well: http://github.com/benschwarz/amnesia
Any references on how to read/interpret this results?