Open Stack

It's always a trade-off with generic vs context-specific caching. You
can usually be more efficient and provide a better UX with
context-specific caching, but it can be a bit more work.

For Nova (and any distributed application along these lines) I think
we need to use context-specific active caching. Punting on it doesn't
give the large deployments many options to scale, you are forced into
generic caching and the UX may always suffer from it. By providing
context-specific active caching hooks we can greatly increase our
usability and efficiency.

-Eric

On Wed, Mar 16, 2011 at 06:33:35PM +0000, Glen Campbell wrote:
> Instead of building data-specific caching (which always worries me), you
> could simply build the service to return the data directly, then add a
> "Cach-Control: max-age=NNN" header to the result. That way, users who
> wanted to improve their performance could add a squid layer (or other
> caching HTTP proxy) to their endpoints and ensure consistency within the
> cache max-age range (for example, max-age=300 would ensure consistency as
> of 5 minutes ago). If the user prefers consistency over performance,
> simply bypass the cache.
> 
> 
> In that manner, the "consistency vs. performance" decision is left up to
> the cloud administrator.
> 
> On 3/16/11 12:58 PM, "Paul Voccio" <paul.voccio at rackspace.com> wrote:
> 
> >Ed,
> >
> >I would agree. The caching would go with the design tenet #7: Accept
> >eventual consistency and use it where it is appropriate.
> >
> >If we're ok with accepting that the list may or may not always be up to
> >date and feel its appropriate, we should be good with the caching.
> >
> >pvo
> >
> >
> >On 3/16/11 11:45 AM, "Ed Leafe" <ed.leafe at rackspace.com> wrote:
> >
> >>On Mar 16, 2011, at 12:23 PM, Paul Voccio wrote:
> >>
> >>> Not only is this expensive, but there is no way I can see at the moment
> >>>to do pagination, which is what makes this really expensive. If someone
> >>>asked for an entire list of all their instances and it was > 10,000 then
> >>>I would think they're ok with waiting while that response is gathered
> >>>and returned. However, since the API spec says we should be able to do
> >>>pagination, this is where asking each zone for all its children every
> >>>time gets untenable.
> >>
> >>    This gets us into the caching issues that were discussed at the last
> >>summit. We could run the query and then cache the results at the
> >>endpoint, but this would require accepting some level of staleness of the
> >>results. The cache would handle the paging, and some sort of TTL would
> >>have to be established as a balance between performance and staleness.
> >>
> >>
> >>
> >>-- Ed Leafe
> >>
> >
> >
> >_______________________________________________
> >Mailing list: https://launchpad.net/~openstack
> >Post to     : openstack at lists.launchpad.net
> >Unsubscribe : https://launchpad.net/~openstack
> >More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> Confidentiality Notice: This e-mail message (including any attached or
> embedded documents) is intended for the exclusive and confidential use of the
> individual or entity to which this message is addressed, and unless otherwise
> expressly indicated, is confidential and privileged information of Rackspace.
> Any dissemination, distribution or copying of the enclosed material is prohibited.
> If you receive this transmission in error, please notify us immediately by e-mail
> at abuse at rackspace.com, and delete the original message.
> Your cooperation is appreciated.
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp