Ugh (reply vs reply-all again) On 03/23/2012 02:58 PM, Joshua Harlow wrote: > Right, > > Lets fix the problem, not add a patch that hides the problem. > > U can’t put lipstick on a pig, haha. Its still a pig...
When stuff is expensive to compute, caching is the only option (yes?). Whether that lives in memcache, a db or in a dict. Tuning sql queries will only get us so far. I think creating custom view tables is a laborious and error prone tact ... additionally you get developers that start to depend on the view tables as gospel. Or am I missing something here? -S > On 3/22/12 8:02 PM, "Mark Washenberger" > <mark.washenber...@rackspace.com> wrote: > > This is precisely my concern. > > It must be brought up that with Rackspace Cloud Servers, nearly > all client codes routinely submit requests with a query parameter > "cache-busting=<some random string>" just to get around problems with > cache invalidation. And woe to the client that does not. > > I get the feeling that once trust like this is lost, a project has > a hard time regaining it. I'm not saying that we can avoid > inconsistency entirely. Rather, I believe we will have to embrace > some eventual-consistency models to enable the performance and > scale we will ultimately attain. But I just get the feeling that > generic caches are really only appropriate for write-once or at > least write-rarely data. So personally I would rule out external > caches entirely and try to be very judicious in selecting internal > caches as well. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp