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>
Includes:
1. Logic simplification: no need to call `ObjSelector.Reset` from JS code,
everything could be done inside the Go code. Remove unused mutexes.
2. Do not handle object twice ever: Once handled, any error is expected to be
logged on the JS side and never be handled again. It solves "already removed"
error.
3. Object caching: no need to call bolt's `View` on every object removal: it
blocks other calls and slows down the execution. Read 100 objects (or less if
not available yet), cache them and send to buffered channel.
Signed-off-by: Pavel Karpy <carpawell@nspcc.ru>
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>
Registry module stores information about uploaded objects in bolt database and
allows to verify their validity after a load test.
Also, implemented logic to verify objects uploaded via gRPC and S3 protocols.
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>
