openstack team mailing list archive

[Sandy Walsh <sandy.walsh@xxxxxxxxxxxxx>]

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.washenberger@xxxxxxxxxxxxx> 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.