On Thu, Feb 2, 2012 at 14:05, Yiftach Shoolman <[email protected]>wrote:
> That being said, I would suggest that you take the first direction > (I.e. deploying Memcache on a dedicated node), this way you decouple > your Memcache scaling from Web scaling. > If you have few servers, then this means you will have a few webservers with a lot of unused RAM, and a few memcached servers with a lot of unused CPU. That's a lot of unused hardware, which is rather silly if you're on a tight budget. Also, both the amount of webservers you need, and the amount of cache memory you need is usually proportional to your web traffic, so it makes little sense to do this decoupling. As always, benchmark and monitor your app to find out what's best for you. If you have lots of spare RAM on your websevers, put memcached on them, If you don't, don't do it. If you need more webservers than cache servers, simply don't put memcached on all of them. Or do it anyway. If you need more cache servers than webservers, don't put your webapp on the extra ones. Or do it anyway. But as a *general* rule, putting memcached on your webserver machines is a good idea. > Also u should take into account that in many cases Memcache generates > a lot of network I/O which can slow down your web/app performance if > deployed on the same node. > This makes absolutely no sense at all. If you have two servers and put a webserver and memcached on both, then *half* of all cache requests will be served by localhost and cause no network I/O, and half will go over the network. But if you put a webserver on one and memcached on the other, then *all* cache requests will be over the network, thus doubling the amount of network I/O for the same amount of web requests. /Henrik
