openstack team mailing list archive

[Ewan Mellor <Ewan.Mellor@xxxxxxxxxxxxx>]

> -----Original Message-----
> From: openstack-bounces+ewan.mellor=citrix.com@xxxxxxxxxxxxxxxxxxx
> [mailto:openstack-bounces+ewan.mellor=citrix.com@xxxxxxxxxxxxxxxxxxx]
> On Behalf Of Jay Pipes
> Sent: Wednesday, December 14, 2011 4:41 AM
> To: Michael Barton
> Cc: openstack@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Openstack] Writes are faster than reads in Swift
> 
> On Wed, Dec 14, 2011 at 1:17 AM, Michael Barton
> <mike-launchpad@xxxxxxxxxxxxxxxx> wrote:
> > On Tue, Dec 13, 2011 at 9:21 PM, Huang Zhiteng <winston.d@xxxxxxxxx>
> wrote:
> >> Can anyone explain why Swift doesn't want to utilize page cache _at
> all_?
> >
> > It's an artifact of the use case swift was built for - heavy on
> > writes, and repeat reads (where a cache would help) are very rare.
> > Having that memory available to cache dirents and inodes has a
> > positive impact on performance, since a swift object server has so
> > many files.
> >
> > The object server used to not drop caches if the file was small and
> > the user wasn't authenticated, but I guess that's been factored out
> at
> > some point.  It'd be nice to have that logic pluggable or
> configurable
> > somehow, since it does make swift kind of useless for things it'd
> > otherwise be good at, like serving static files directly to browsers.
> 
> Or static disk image files!

Only if you've got enough RAM on the storage worker node to cache the entire disk image.  Otherwise it's just going to get evicted straight away.

The case where you've got so few, small, disk images that you can cache them all in RAM must be pretty rare.  And if it's not rare in your use-case, I reckon giving that RAM to your Glance nodes and doing the caching there would be just as good if not better.

Cheers,

Ewan.