2

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

Improve this question
4
  • 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. Commented Feb 3, 2012 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. Commented Feb 4, 2012 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. Commented Feb 4, 2012 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. Commented Feb 5, 2012 at 12:17

2 Answers 2

Reset to default
4

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 $.

Improve this answer
1
  • 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! Commented Feb 3, 2012 at 17:22
0

I got some great responses on AWS forums:

https://forums.aws.amazon.com/thread.jspa?messageID=316646&

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

Improve this answer
1
  • 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. Commented Feb 5, 2012 at 12:20

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.