Ask Your Question

Dynamic large objects : Range bytes very SLOW

asked 2014-01-15 05:26:43 -0500

Betezed gravatar image

updated 2014-01-15 11:39:31 -0500

torgomatic gravatar image

Hi everyone,

First of all, please forgive me for my english, I hope you'll understand everything. If you have any question, please ask :)

For some reason, I need to get a dynamic large object with the Range functionality. I have a file movie.iso which is a manifest merging 2 files : movie-1.iso (4Go) and movie-2.iso (3,2Go) For testing purpose, I'm using telnet on a temporary URL :

telnet 80 
GET /v1/AUTH_abcdefghijklm0123456789/ean_chris_0001/movie.iso?temp_url_sig=wxcvbn1213456&temp_url_expires=1389741206 HTTP/1.1
range: bytes=32-42
Connection: Close

So basically, I'm asking for 11 bytes. The server answers correctly after more that 2 min

HTTP/1.1 206 Partial Content
Content-Length: 11
Accept-Ranges: bytes
Last-Modified: Wed, 11 Dec 2013 01:02:06 GMT
Content-Range: bytes 32-42/7215073280
X-Object-Manifest: container/movie-
X-Timestamp: 1386728331.26093
Etag: "xxxxxxxxxxxxxxxxxxxxxxxx"
Content-Type: application/x-iso9660-image
Content-Disposition: attachment; filename=movie.iso
X-Trans-Id: yyyyyyyyyyyyyyyyyyyy
Date: Wed, 15 Jan 2014 11:03:27 GMT
Connection: close

However, when I'm doing this exact same operation (meaning asking for 11 bytes with a range request) on a non-manifest file (for example on movie-1.iso or movie-2.iso), the response is almost instantaneous.

I think that this long delay when asking for some bytes on a manifest file is caused by the fact that the manifest starts with the merging operation and when it finishes its merging, it sends me back the 11 bytes I asked.

So my question is : Do you have any idea on what to do in order to avoid this long delay ?

Thank you in advance for reading and maybe trying to solve my issue ... !

edit retag flag offensive close merge delete


It would help to know the version of Swift and what HTTP intermediaries there are (load balancers, caching proxies, and the like).

torgomatic gravatar imagetorgomatic ( 2014-01-15 11:46:24 -0500 )edit

1 answer

Sort by ยป oldest newest most voted

answered 2014-01-15 11:45:24 -0500

torgomatic gravatar image

Swift isn't the slow one here; within Swift, a range request for a dynamic large object gets turned into range requests for the segments (internally). In your example above, the Swift proxy would make a request to the Swift object server for movie-1.iso with "Range: bytes=32-42", and the object server would return just those bytes.

I'd suspect some proxy or load balancer is interfering. Try making the requests directly to the Swift proxy server, and I'll bet that they're much faster.

edit flag offensive delete link more


Hi, I'm answering very late, but I wanted to thank you for your answer (again !) We found some new ideas to avoid this delay, but we don't know for sure why it took so long... Anyway, again thanks for replying and helping ! Bye :)

Betezed gravatar imageBetezed ( 2014-01-31 06:47:36 -0500 )edit

Ok you were right, because I used swift through OVH, and some changes were made. Now everything works like a charm ! Thanks again for your helpful answer(s) ("s" because you helped me twice !)

Betezed gravatar imageBetezed ( 2014-02-28 03:31:36 -0500 )edit

Betezed, what did you do exactly to solve the delay with your configuration on OVH ?

Bertrand V gravatar imageBertrand V ( 2014-03-30 17:43:51 -0500 )edit

Hi Bertrand V, I didn't do anything. Some OVH side changes were made. I think they just changed the way they handled the range feature for the dynamic large objects. Are you facing this delay issue ?

Betezed gravatar imageBetezed ( 2014-03-31 05:09:39 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools



Asked: 2014-01-15 05:26:43 -0500

Seen: 706 times

Last updated: Jan 15 '14