Agreed. From experience, in all likelihood, this is _not_ what you want to do (it sounds like you're talking about maintaining a memcached server on each app server). If you're even thinking about scaling by CPU, you should be able to afford at least one m1-small server lying around with memcached using all of the memory you can throw at it, and bring up app servers separate, as needed. If for one reason or another you absolutely, positively need to have memcached running locally, you're almost certainly better off having a tiered caching strategy utilizing a caching system native to whatever framework you're using; there was a discussion here about that a week or so ago.
On Tue, Feb 10, 2009 at 6:37 PM, a. <[email protected]> wrote: > > can't you just have a memcached node and an appserver node? appservers > started later could use the same memcached instance. > > > > On Feb 11, 2009, at 3:35 AM, Travis Bell wrote: > > >> Hey Dustin, >> >> Keep in mind I wouldn't keep these instances running... they would be >> brought up and down as the load needed them to be so maybe I am >> missing a key step (which trust me, I most certainly could be) but I >> am not sure how the new instance would even get used based on what you >> said. >> >> Example 1: load gets high so a new EC2 instance is triggered. Once >> it's up, I reload the config on my load balancer so requests are split >> across 2 instances, instead of 1. The original instance is going to >> have hundreds of thousands of items cached when the second (new) >> instance does not. Whenever a requests gets forwarded to this new >> instance it will result in a cache miss and have to go fetch the item >> again. >> >> It seems to me having to re-fetch the item is a bit of a waste since >> it's already cached on the first server... this is what I am trying to >> solve. >> >> Regarding saturating memcached, it's less about that and more about >> all the other things this server is doing behind the scenes so moving >> memcache to a new instance can spare the first box when it is needed. >> >> Thanks in advance for any more info you guys can provide! >> >> >> > -- Marc Bollinger [email protected]
