[Openstack] [Swift] Getting better performance by disabling container DB updates?

Chuck Thier cthier at gmail.com
Thu Mar 20 14:50:01 UTC 2014


Hi Shrinand,

For your use case, it would certainly lower the overall latency, and likely
increase throughput.  The downside is that the client has to track all of
the objects, and you loose some of the other features like usage.

Is it viable for swift?  That's a tough question.  I think could be worth
exploring if someone is willing to work on a patch (and the hypothesis
would be fairly easy to test with a small set of changes).  The downside is
that it does diverge a bit from the general purpose/use case of swift.

I think a better end result would be to figure out how to make swift work
better for your use case as is.  The summit would be a great place to
discuss this further if you would like to propose a discussion about it at
http://summit.openstack.org/

--
Chuck


On Thu, Mar 20, 2014 at 1:09 AM, Shrinand Javadekar <shrinand at maginatics.com
> wrote:

> Hi,
>
> I recently came across an object store that could disable container
> listing and thereby give better performance. By disable, it meant that
> a call to list the entries in a container would simply return an empty
> status code of 200 without any object names.
>
> I guess this is possible only if the entire object store is considered
> to as a single namespace. When objects are put into the object store,
> the DB keeping track of objects in a container isn't
> populated/updated. Not updating this DB helps drive better
> performance. I haven't been able to get details about how they achieve
> this.
>
> Is something like this viable for Swift?
>
> -Shri
>
> _______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140320/0b7a9d1c/attachment.html>


More information about the Openstack mailing list