I am currently having an m1.large instance acting as a memcache server.

I would like to replace that with 2 m1.small nodes for High Availability more or less for the same cost.

But I am concerned about the impact of the moderate IO performance of m1.small.

I read the following as if moderate IO would affect network system as well.

Not sure if the fact that there would be more nodes counterbalance the more limited IO capacity of the small instances.

Anyone had experience with memcache on these instance types that can comment?

Many thanks in advance

  • I'd suggest it depends heavily on how your app uses Memcached. I suspect that the result will be improved availability but decreased performance - especially if your data changes frequently. High availability suggests that any data changes must be replicated to (at least) one other node - which will increases network usage between two instances, and reduce that available to 'clients'. Also, since an m1.small shares its resources between more instances, the variability in performance is much larger. Your best bet would be to benchmark it yourself to find out. – cyberx86 Feb 3 '12 at 2:24
  • many thanks! Just a note on memcache, it does not replicate and different data is stored on different nodes. Yes this means that when a node goes down, a certain percentage of the data you are caching is lost. The more nodes there are the less dramatic this is for the app performance. – webgr Feb 4 '12 at 18:00
  • If you wish, Memcached can be setup to replicate using a patch such as repcached or using an application with a compatible protocol such as Membase. The I/O capacity referenced by AWS is not (just) disk I/O, but includes network I/O (the reason it affects disk I/O is because EBS disks are attached over the network). Of course, since you have tested out the multi-node approach it out and found it to offer good performance - it is definitely the way to go. – cyberx86 Feb 4 '12 at 21:36
  • thanks for elaborating! In our use case cached data can be ephemeral so replication is not a requirement. We ll have an open eye for membase (or redis) in case a different use case requires more reliability. – webgr Feb 5 '12 at 12:17

To my knowledge the moderate IO capacity is for disks, and memcached uses memory. Probably you will have some overhead with the synchronization, but the best thing you can do is to test it. AWS EC2 offers you the chance to test it for a couple of $.

  • I ll test it on our production environment during the weekend. Can't really judge by our staging environment. Since I also hear IO can be variable on such instances I am looking for advice from people that might have been running memcache on m1.small for long time already. Hope you are right about the IO only affecting the disk performance. In any case I ll report back with the results of my test! – webgr Feb 3 '12 at 17:22

I got some great responses on AWS forums:


And the initial performance on the production environment does not seem to be any worse than when we had that single larger instance.

  • Having reviewed performance for a couple of days I do see some variance in performance, not significant enough though so we ll take the availability for the same cost. In the future we might consider using larger nodes in a cost-benefit fashion. – webgr Feb 5 '12 at 12:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.