multi ranges per request are interesting, i wasn't even aware of that existing in the wild

ah gotcha

It doesn't

this is amazing info, thanks for the detail!

Actually, I think I've blanket assumed we won't support multi range

I'll have to talk to the PM about it. It's technically very easy but there are potential billing implications

personally i'm not sure how useful it would be for us

Otherwise I would have done it when I implemented ranges

It's niche

But a popular feature & really weird other providers don't do it

sounds like more for reducing request load

when you're doing a lot of random access

You can do some interesting things (e.g. random access to several files within a zip file efficiently)

that is predictable in advance

exactly and those crazy backends for sqlite etc

And yeah, reducing charges for request load if you know you have a bunch of random accesses known at once

ah yeah, if you have the zip file offset index available or you fetch that first, i see

but i agree, for most cases like media especially a single range is sufficient

zip has a central directory. so you fetch that and then you have all the offsets of all files

actually mp4 containers are like that too, i take it back - it would be great to have multi-range requests! : )

On my very long list of features I want to add, transparent zip and tar support is one of them. Upload a tar/zip file and it expands automatically on our end - you still pay for each file but it's a more efficient upload if you have lots of small files. Same on the download side

Is it OK if each range gets billed as a read?

I think you're asking for free multi range reads, right?

err not free but the cost of 1 GET

i mean free is best, but yea, latency win would be worth it in many cases (fewer larger ranges)

this actually isn't a problem for us because we already do our own sharding into folders, but i'm curious: with R2, is it best to balance objects randomly into different folders to get the best distribution across different nodes/servers/etc?

Really? Couldn't you just issue those ranged reads in parallel?

(rather than dumping everything into a single folder at the top level of the bucket)

Hmm... I guess you're right - there would maybe be a latency win

depends on the client connection