If you went with the application cache in your case, how would you handle cache invalidations? Would you have to develop a mechanism to tell all of your front end machines that a certain key has expired, or isn't your application affected if it gets stale data from the cache? Yes, memcached is slower than a local application cache, but it's synchronized which means that if one of your front end machines update or delete a key, that change is visible immediately to your entire application. To compare a local application cache with memcahed, you would have to factor in both the network overhead of fetching something from memcached, and the network overhead of synchronizing your local application caches. The latter case scales really, really badly if you have a lot of front end machines.
/Henrik On Tue, May 12, 2009 at 10:23, JonB <[email protected]> wrote: > > Hi All, > > I've recently been looking at memcached for use in a project here - > I've looked at the site, read the FAQ, and whatnot - but still have a > couple of questions... > > At this point in the project - we need to cache reads to a MySQL > server. I'm faced with a choice of either writing our own caching > layer - or going with memcached. > > The system has a number of front end machines, which at the moment all > query a single back end MySQL server. The machines are predominately > doing read queries, and largely for the same data (i.e. Machine 'A' > will query for 'x' - Machine 'B' is then also likely to query the same > 'x' - and that same query may get run a few hundred to a few thousand > times in a row). > > Most of the queries are relatively 'cheap' on the SQL side - a few are > quite expensive. At this stage we're more concerned with the volume of > queries (several hundred a second) and would rather see the SQL server > just handling predominately writes. > > This kind of tips the balance in favour of memcached (as our own > caching layer won't spread between machines). > > My only concern is the queries we're dealing with generate tiny result > sets. Sometimes it's literally a query that returns a single 'true/ > false' value, other times, it's queries that return a couple of > hundred bytes - max. > > Whilst I realise, running this through memcached will 'work' (and > alleviate the load on the MySQL server for repetative reads) - I'm not > sure how 'efficient' it's going to be? > > In this case do you think/guesstimate we'd be better with local > application caching - or is the overhead on memcached sufficiently > small that using it for tiny data sets is worth while? (considering > it'll 'spread' the cache between machines - which ours won't). > > -Jon
