Open Stack

Well... What results did you get?  What did you expect?  What do you hope
to achieve?

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.

But I'm still game for micro optimization too!

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.

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).

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.

-Clay


On Thu, Mar 6, 2014 at 11:23 PM, Ivan Pustovalov <ip.disabled at gmail.com>wrote:

> HI!
> I have a cluster of 5 nodes with 3 replicas. All of the servers (e.g.
> proxy, account, object, container )
> are installed on a single server, and I have 5 of these servers.
> I send put object requests from one testing thread and check client
> response time from cluster.
> And obtained results did not satisfy me.
> 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.
>
> 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.
> How I can reduce this time loss and what are best practices for tuning?
>
> --
> Regards, Ivan Pustovalov.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140307/5f315cab/attachment.html>