Yes, but how would you do cache invalidations? Right now in your existing application, you don't have to worry about when the underlying data changes, since all reads go to the one and only storage of this data. But if you add a cache layer, you have to start worrying about cache invalidation. If you have a local cache, and one machine changes the underlying data, you somehow have to tell all your other machines to refresh parts of their caches as well. How would you do that? How much would that mechanism cost?
On the other hand, if you use memcached, the cache is shared, so if one machine changes what's in memcached, all other machines will pick up the new values immediately. This way, updates are cheaper, but at a higher read cost. What's the ratio of updates/reads in your application? Or is cache invalidation irrelevant for your application? Will it run fine with stale data? /Henrik On Tue, May 12, 2009 at 16:07, JonB <[email protected]> wrote: > > If we went with a local cache, it wouldn't be shared between machines > - in reality, a lot of the front end machines would end up with almost > 'identical' caches (as they often run the same queries) - but it > wouldn't be shared. > > Expiry would be the same as memcached - when data's added to the local > cache, it gets an 'expire by' time stored with it. > > By the sound of it, memcached will work - it'll cost me network calls > (but not to the MySQL server) - the only remaining doubt I have is > over the data being stored in it. > > Not a lot of our data can be agregated before being cached - so we're > left again, looking in the cache for very small bits of data (a few > bytes to a few hundred bytes). > > I'll have to sit down and work out where in the application it's > likely to sit, and whether the cost of the network calls etc. to get a > few bytes, is actually worth it. > > I guess having a 'localhost' cache would avoid some of the overhead, > as would UDP. > > I have a feeling this is all going to end in a 'write it and see' kind > of solution :) > > At least in my head it seems like it might play out - afterall, even > if the SQL queries usually return very little data - some of them are > quite expensive for the server to run, and very static in nature - so > we're trading cycles on the front end (making it less efficient) to > push that load to the front end, rather than the MySQL servers.
