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

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

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

Need to support new write, read, delete scenario for longevity tests. Read should read in loop written objects, and not read deleted objects
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)?
Author
Member

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

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
Owner
  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.
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.
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: TrueCloudLab/xk6-frostfs#148
No description provided.