On Thu, Nov 20, 2008 at 14:00, Jitendra <[EMAIL PROTECTED]> wrote: > > Hi, > Thanks for the updates. > > I can't just predict the amount of data to be stored in the cache.
That's usually pretty tough, but that shouldn't really matter, what's important with a cache is the hit ratio, i.e. how often your application can get the data from the cache instead of from your data storage. If your hit ratio is too low, then it might be a good idea to increase the size of your cache. > So I wan't to start another instance when one is full. This makes no sense. When your have filled your memory, memcached will start throwing out the least recently used items first. This is good, these items are probably not needed right now by your application anyway, so when they are discarded, they are least likely to cause a cache miss. How much of the cache is used or how many evictions have happened is a bad metric for measuring cache performance, you can have a great hit ratio, and still have lots of evictions, and it's only your hit ratio that is the important metric for the performance of your application. Only if your hit ratio is going down might it be useful to increase your cache size or go over your expiration times. Also, adding a memcached instance during runtime is pretty bad since it will change the key distribution. Some clients are less disruptive than others, specifically the "ketama" method minimizes the impact, but if you have n servers and add one, then at least 1/(n+1) of all your items will be moved to the new server, and since that is empty, all those items need to be fetched from your data storage again. You also have no real idea which specific items will have to be re-fetched. Your application must be able to handle that *ANY* get of an item from memcached may fail and return nothing. Therefore, using memcached as some sort of primary data storage is a really bad idea. /Henrik
