get: Add --range-size to have a random but a defined range pattern

[vadmeste]

--range-size and --range will create GET requests with random offset but with fixed range

[vadmeste]

We can discuss during the next week if we should drop this PR or not @klauspost

[klauspost]

Lint fix at: #303

[klauspost]

In terms of keeping this simple - could you explain why this is needed?

It seems like it would break pretty much all scenarios since they upload multiple objects.

[vadmeste]

This is originally written to benchmark server caching, so warp clients will read the same object multiple times, but yeah I think it is better if we make the orchestor warp client to generate a list of objects and share it with other warp clients before starting to benchmark.

[klauspost]

The multipart benchmark does this already:

warp/cli/multipart.go

Line 94 in 1723cdb

b.ExtraFlags = map[string]string{"_upload-id": b.UploadID, "noprefix": "true"}

[klauspost]

You may want the initiator to create the objects - otherwise they will all be fighting to create it.

Note however that this will invalidate the PUT benchmark. TBH I just think you want to remove this and just have each client upload a few objects.

[harshavardhana]

is this PR still planned? if not please close.

[klauspost]

@vadmeste Reach out if you still need it, and I can adjust it as needed.

[harshavardhana]

we have a customer requirement on this can we finalize this ?

[klauspost]

What is the point of the single object name?

You can use --objects=1 (which will create one per client) or --list-existing... which will just use whatever is there.

[harshavardhana]

The requirement is that have a bunch of large objects for example and then you can specify a range warp decides to generate list of range requests that randomly hit these objects and provide results, that's all.

[klauspost]

@harshavardhana Yes. But not sure why the custom name would be needed for that (and it will break in distributed). To me it seems like it should just be removed from this PR.