Henrik, thanks for the response. About option 1, in a multi threaded application, where you need caching/invalidation/atomic increment commands and many stats, I think memcache is a good option even for local caching. Memcache gives us a stable, extremely efficient implementation doing all those things. Its a trade off, whether you want to build this in an application or use memcache which is fast enough to serve the requirement, saving our a lot of engineering time in developing and maintaining it in application.
About option 2, by single point of failure I meant about the response time. We are using is as cache only and not a data store. We need to respond within 85ms and if memcache goes down, then all our servers(100s of) will be hitting the mysql about 250 times for each request. In short, we will not be able to meet our time constraints in that case.e On Apr 22, 4:52 pm, Suraj <[email protected]> wrote: > Thanks a lot dormando for the reply. It is really valuable to us. > > On Apr 22, 11:28 am, dormando <[email protected]> wrote: > > > > > > > > > Memcached's architecture is a set of tradeoffs: > > > - Add a little network roundtrip latency > > - Gain global atomic invalidation > > - Gain linearly expanding cache size > > > Global invalidation means your cache can be more useful, and perhaps you > > can use it in more places. > > > Expansive cache means (if you have enough data) that you hit your backend > > less often, which tends to make up for the "speed loss" from going over > > the network. > > > If neither of those tradeoffs are valueable to you, don't set it up that > > way. > > > On Sat, 21 Apr 2012, Suraj wrote: > > > Hi, > > > > We are having a scenario, where for each request, we call memcache > > > about 250 times. Our memcache data size is not much and totals to > > > around 1 GB. Multiget is not an a straight forward option, as our > > > cache calls are scattered across the code and depends on the business > > > scenario. > > > > Each server nearly serves 10 million requests per day and a cluster > > > combined serves nearly 1 billion requests a day. We are having a > > > gigabit ethernet. Our server side response time for each request is > > > and should be < 85 ms. > > > > What approach should be ideal for this scenario? > > > > 1. Run memcache on each server on unix socket. > > > This will reduce the network latency but increase the cache miss ratio > > > a bit and data redundancy, as nearly same data is present on each > > > node of the cluster. > > > We are having similar setup and see around 85% cache hit. Our expiry > > > time varies for different keys. > > > > or > > > > 2. Have a distributed memcache layer. This will probably increase the > > > cache hit ratio to more than 99%. > > > But this will add the network latency and may be a single point of > > > failure. > > > > I did a very basic get bench marking on a low end machine. > > > 1. 100,000 get, 1 thread, memcache and benchmarking script on same > > > machine - 1.233s > > > 2. 100,000 get, 1 thread, memcache and benchmarking script on > > > different machine - 9.538s > > > > From this numbers, approach 1, the one we are doing right now seems to > > > be a better one. > > > Please let me know your opinion, about what approach seems to be > > > better or if there is any different suggestion. > > > > Thanks.
