Hi Rick, I found the problem. I placed a hardware balancer in front of the proxy server. The balancer lost some packets because of a faulty network interface. Your tip was excellent.
Thanks Klaus -----Ursprüngliche Nachricht----- Von: Rick Jones [mailto:rick.jon...@hp.com] Gesendet: Freitag, 31. Mai 2013 19:17 An: Klaus Schürmann Cc: openstack@lists.launchpad.net Betreff: Re: [Openstack] Swift performance issues with requests On 05/31/2013 04:55 AM, Klaus Schürmann wrote: > May 31 10:33:08 swift-proxy1 proxy-logging 10.4.2.99 10.4.2.99 > 31/May/2013/08/33/08 GET /v1/AUTH_provider1/129450/829188397.31 HTTP/1.0 200 > - Wget/1.12%20%28linux-gnu%29 > provider1%2CAUTH_tke6408efec4b2439091fb6f4e75911602 - 283354 - > txd4a3a4bf3f384936a0bc14dbffddd275 - 0.1020 - > May 31 10:33:26 swift-proxy1 proxy-logging 10.4.2.99 10.4.2.99 > 31/May/2013/08/33/26 GET /v1/AUTH_provider1/129450/829188397.31 HTTP/1.0 200 > - Wget/1.12%20%28linux-gnu%29 > provider1%2CAUTH_tke6408efec4b2439091fb6f4e75911602 - 283354 - > txd8c6b34b8e41460bb2c5f3f4b6def0ef - 17.7330 - <<<<<<<<<<<<<< Something I forgot to mention, which was the basis for my TCP retransmissions guess. Depending on your kernel revision, the initial TCP retransmission timeout is 3 seconds, and it will double each time - eg 3, 6, 12. As it happens, the cumulative time for that is 17 seconds... So, the 17 seconds and change would be consistent with a transient problem in establishing a TCP connection. Of course, it could just be a coincidence. Later kernels - I forget where in the 3.X stream exactly - have the initial retransmission timeout of 1 second. In that case the timeouts would go 1, 2, 4, 8, etc... rick _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
