<div dir="ltr">Hi Vincenzo,<div><br></div><div>First thank you for this work. It is always interesting to see different data points from different use cases.</div><div><br></div><div>I noticed a couple of things and would like to ask a couple of questions and make some observations.</div>
<div><br></div><div>Comparing a high level HTTP/REST based api (swift) to a low-level C based api (librados) is not quite an apples to apples comparison. A more interesting comparison, or at least another data point would be to run the same tests with the rados gateway which provides a REST based interface. I believe that what you attribute to differences between the performance of the CRUSH algorithm and swift's ring are more likely attributed to the extra overhead of a high level interface.</div>
<div><br></div><div>An optimization is made for ceph by adding an extra disk to store the journal, which specifically enhances the the small object performance, for a total of 3 spindles per node. Yet, swift was only given 2 spindles per node, thus giving ceph quite a substantial more overall IO to work with. </div>
<div><br></div><div>In several of the results, the graphs show a significant reduction of throughput with swift going from 1 container to 20 containers with the same sized object. In a correctly configured swift cluster, performance for PUTs at high concurrency will always be faster with more containers. Container operations are not part of the GET path, so the number of containers will not effect GET performance. This leads me to believe that either swift isn't properly configured, or the client is doing something non-optimal for those cases.</div>
<div><br></div><div>The eventual consistency semantics of swift are reported incorrectly. For 3 replicas, swift will stream out all 3 copies of the object to their locations at the same time, and only return success if at least 2 of those are successful. This is somewhat similar to the behavior of ceph. Replication in swift is only used when there are failures.</div>
<div><br></div><div>I would also suggest expanding the data set a bit. For example, test the performance after the system has been filled more than 50%. I would also highly recommend testing performance when there are failures, such as a dead disk, or one of the nodes going away.</div>
<div><br></div><div>Thanks,</div><div><br></div><div>--</div><div>Chuck</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 12, 2014 at 3:46 AM, Vincenzo Pii <span dir="ltr"><<a href="mailto:piiv@zhaw.ch" target="_blank">piiv@zhaw.ch</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">As promised, the results for our study on Ceph vs Swift for object storage: <a href="http://blog.zhaw.ch/icclab/evaluating-the-performance-of-ceph-and-swift-for-object-storage-on-small-clusters/" target="_blank">http://blog.zhaw.ch/icclab/evaluating-the-performance-of-ceph-and-swift-for-object-storage-on-small-clusters/</a></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">2014-06-06 20:19 GMT+02:00 Matthew Farrellee <span dir="ltr"><<a href="mailto:matt@redhat.com" target="_blank">matt@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On 06/02/2014 02:52 PM, Chuck Thier wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have heard that there has been some work to integrate Hadoop with<br>
Swift, but know very little about it. Integration with MS exchange, but<br>
could be an interesting use case.<br>
</blockquote>
<br></div>
nutshell: the hadoop ecosystem tends to integrate with mapreduce or hdfs. hdfs is the hadoop implementation of a distributed file system interface. there are a handful of others - <a href="http://wiki.apache.org/hadoop/HCFS" target="_blank">http://wiki.apache.org/hadoop/<u></u>HCFS</a> - including one for swift. so where you might access a file in via hdfs:///... you can also swift:///... for processing by mapreduce or other frameworks in hadoop.<br>
<br>
best,<br>
<br>
<br>
matt<div><div><br>
<br>
<br>
______________________________<u></u>_________________<br>
Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack</a><br>
Post to : <a href="mailto:openstack@lists.openstack.org" target="_blank">openstack@lists.openstack.org</a><br>
Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack</a><span class="HOEnZb"><font color="#888888"><br>
</font></span></div></div></blockquote></div><span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><br clear="all"><div><br></div>-- <br><div dir="ltr"><div>Vincenzo Pii<br>
</div>Researcher, InIT Cloud Computing Lab<br>Zurich University of Applied Sciences (ZHAW)<br><a href="http://www.cloudcomp.ch/" style="color:rgb(17,85,204)" target="_blank">http://www.cloudcomp.ch/</a><br>
</div>
</font></span><br>_______________________________________________<br>
Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
Post to : <a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a><br>
Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
<br></blockquote></div><br></div>