Open Stack

My guess is the object data need to be transmitted to Swift cluster before
the status code returned.
It can't be returned immediately before 2/3 I/O completed. Otherwise it is
not consistent to tell client
it succeed.

-Edward Zhang



                                                                           
             Shrinand                                                      
             Javadekar                                                     
             <shrinand at maginat                                          To 
             ics.com>                  "openstack at lists.openstack.org"     
                                       <openstack at lists.openstack.org>     
             2014-06-24 下午                                            cc 
             03:05                                                         
                                                                   Subject 
                                       [Openstack] [Swift] PUT requests    
                                       sensitive to latency?               
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Hi,

I have a single node swift cluster. I measured the time taken to
complete a PUT request that originated from three different client
machines. Each client was writing a single 256K byte object.

Note that the time measured was only the time taken on the Swift
cluster itself. I started the timer after the request was received by
the swift proxy-server process and stopped it when that method
returned an HTTP status to the client. This is not the time on the
client side and therefore *ideally* should not be affected by the
latency between the client and the Swift cluster.

However, it appears that the above is not true. The time required to
complete the request is related to the latency between the client and
swift cluster.

Here are the results:

* Client 1:
Ping time 28ms
PUT request time: ~180 ms

* Client 2:
Ping time 4 ms
PUT request time: ~35 ms

* Client 3:
Ping time 0.04 ms
PUT request time: ~10 ms

Details about the experiment:

* This is a single node Swift installation (not devstack) and uses
SSDs to store metadata as well as data. This is just a test setup. In
production, we won't have SSDs for storing data.
* The above numbers are average of 50 PUT requests.
* The Swift cluster was not being used for anything else during the
experiment.
* The client used was the jclouds library written in java. I had
disable a config option that used the Expect 100-Continue header; i.e.
the requests were not using the Expect 100-Continue header.
* I tried increasing the size of the following options in the
proxy-server.conf and restarting Swift.
disk_chunk_size = 262144
network_chunk_size = 262144
...
[app:proxy-server]
object_chunk_size = 262144
client_chunk_size = 262144

However, this didn't show any improvement in the time required for PUT
requests.

Am I missing anything? Does Swift require an extra round trip from the
client for completing PUT requests? Any ways of avoiding that?

Thanks in advance.
-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/20140624/5d1e5451/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140624/5d1e5451/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic32097.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140624/5d1e5451/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140624/5d1e5451/attachment-0002.gif>