<div dir="ltr">Well... What results did you get?  What did you expect?  What do you hope to achieve?<div><br></div><div>How are you balancing your client requests across the five nodes?  I'm not sure you're going to get anywhere near 2000^H^H requests a second from a single thread (!?) - Swift's performs best against many concurrent requests.</div>
<div><br></div><div>But I'm still game for micro optimization too!<br><div><br></div><div><div>It's sort of understood that HTTP overhead will have a more and more non-trivial impact on requests as the size of the objects get smaller.<br>
</div><div><br></div><div>I would say the *biggest* benefit of Swift's expect 100 continue support is to avoid transferring data needlessly to servers that can't support it (I'm speaking particularly on the 507 case here) - but if someone had the numbers to prove out dramatic improvement on small requests I could see it possibly becoming optional (error limiting on 507 is pretty aggressive).</div>
<div><br></div><div>There's other benefits to expect 100 continue, but I could imagine a deployment where the benefit is negligible and I'd listen if anyone had numbers to better understand the cost.</div><div><br>
</div><div>-Clay</div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 6, 2014 at 11:23 PM, Ivan Pustovalov <span dir="ltr"><<a href="mailto:ip.disabled@gmail.com" target="_blank">ip.disabled@gmail.com</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">HI!<div>I have a cluster of 5 nodes with 3 replicas. All of the servers (e.g. proxy, account, object, container )<br clear="all">
<div>are installed on a single server, and I have 5 of these servers.</div><div>
I send put object requests from one testing thread and check client response time from cluster.</div><div>And obtained results did not satisfy me. </div><div>When I was researching tcp traffic, I found time loss on waiting HTTP 100 from object servers, 10-15 ms on each and 10 ms on proxy while checking quorum. </div>

<div><br></div><div>In my case, users can put small objects (e.g. 16 kbytes) into the cloud and I look forward to a load of 2000 requests per second. This time loss significantly reduces cloud performance.</div><div>How I can reduce this time loss and what are best practices for tuning?</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div>-- <br>Regards, Ivan Pustovalov.</font></span></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>