Return an interface which can be converted to `io.Reader` as well as
report payload size and hash.
Signed-off-by: Evgenii Stratonikov <e.stratonikov@yadro.com>
1. Make it easier to change new parameters.
2. Fix a bug where the generator was created even for read-only
scenarios.
Signed-off-by: Evgenii Stratonikov <e.stratonikov@yadro.com>
Previous iteration was bad, because `Logger` instance was shared and
endpoints in different VUs were overriding each other.
New interface is much better, it supports logger extension in any
context with arbitrary fields.
```
const l = logging.new().withFields({endpoint: "my endpoint"});
...
l.withField("cid", container).info("not found");
```
Signed-off-by: Evgenii Stratonikov <e.stratonikov@yadro.com>
To fine-tune read/write/delete load we need to have separate sleep
intervales for readers/writers/deleters.
The changes were originally authored by anatoly@nspcc.ru <anatoly@nspcc.ru>
Signed-off-by: Vladimir Domnich <v.domnich@yadro.com>
1. Added simple lock mechanism to reset obj selector. This prevents
most of concurrency issues when multiple VUs try to reset selector.
2. Added logic to delete objects to grpc and s3 scenarios.
3. Added registry support to http scenario.
4. Deletion logic was not implemented for http scenario, because
http gateway does not provide web-method to delete objects.
Signed-off-by: Vladimir Domnich <v.domnich@yadro.com>
It improves payload generation in our scenarios. Current implementation
of scenarios generates single random payload at the start and then sends this
same payload on every request. More realistic test is to generate unique payload
for each request. However, this is an expensive operation that can easily cause
a bottleneck on K6 side when we run multiple writing VUs. So instead we generate
a random buffer with some extra bytes and then take slices of this buffer thus
producing a random payload for each request.
Signed-off-by: Vladimir Domnich <v.domnich@yadro.com>
