Need to support write, read, delete scenario for longevity tests #148

New Issue

Open

opened 2024-06-19 09:40:17 +00:00 by mmalygina · 3 comments

mmalygina commented

2024-06-19 09:40:17 +00:00

Collaborator

Need to support new write, read, delete scenario for longevity tests. Read should read in loop written objects, and not read deleted objects

fyrchik commented

2024-06-19 11:42:40 +00:00

Owner

The tricky problem is to avoid simultaneous GET/DELETE on the same object.
It can be solved with a performance penalty in multiple ways.

It is also not obvious what we want here. For small background load scenarious we can run multiple k6 processes. Could you elaborate a bit what is the desired steps for your scenario (every object should be PUT then GET then DELETED, or something else)?

The tricky problem is to avoid simultaneous GET/DELETE on the same object. It can be solved with a performance penalty in multiple ways. It is also not obvious what we _want_ here. For small background load scenarious we can run multiple k6 processes. Could you elaborate a bit what is the desired steps for your scenario (every object should be PUT then GET then DELETED, or something else)?

mmalygina commented

2024-06-20 12:17:35 +00:00

Poster

Collaborator

We want long load running for week up to months. First we start write load with simultaneous read and delete, then when cluster is filled up to f.e 70%, we stop load and start delete and read load, after gc on cluster regains space we stop delete and read and start normal load write, read, delete

fyrchik commented

2024-06-21 06:14:14 +00:00

Owner

We can start 2 k6 processes which write to separate registries, this seems to be a solution.
We can also add command (like registry-exporter) which can split 1 registry DB into 2.

1. We can start 2 k6 processes which write to separate registries, this seems to be a solution. 2. We can also add command (like registry-exporter) which can split 1 registry DB into 2.