Many shards snapshots challenge for elastic/logs #294
Conversation
This commit adds a new challenge for many-shards that benchmarks ES performance while taking several (specified by the track parameter `snapshot_counts`) snapshots. The intention is to initially use it for tracking regressions by visualizing the `service_time` of the `wait-for-snapshots` task. This PR depends uses the Rally operation `wait-current-snapshots-create` operation (introduced in elastic/rally#1542).
dliappis
added
the
new workload
| "clients": {{ p_bulk_indexing_clients }} | ||
| }, | ||
| { | ||
| "name": "register-snapshot-repository", |
There was a problem hiding this comment.
I noticed that no existing track uses Rally's delete-snapshot-repository operation, any idea why? I guess it would be more robust for local execution.
I'm mostly asking for the challenge I'm working on, I don't think this should block this pull request!
There was a problem hiding this comment.
That's a good question. Such an operation would make sense when >1 iterations of the same challenge run within the same use case. Even then, I am not sure that one needs to delete the repository; I was under the impression that if you re-register the same repository with the exact same parameters, it'll just verify the repository (we could test that). This is probably what happens when several sequential restorations happen -- in the form of several experiments including ES stop/starts -- in logging query benchmarks.
There was a problem hiding this comment.
Yeah I think it's only useful if you made a mistake when developing the track and want to start from a clean slate.
A few older many shards challenges got replaced with a new one. Updated README to reflect this. Also adding a few missing challenges and fixing a few typos. Relates to: elastic#303 Relates to: elastic#294
A few older many shards challenges got replaced with a new one. Updated README to reflect this. Also adding a few missing challenges and fixing a few typos. Relates to: elastic#303 Relates to: elastic#294
This commit adds a new challenge for many-shards that benchmarks ES
performance while taking several (specified by the track parameter
snapshot_counts) snapshots.The intention is to initially use it for tracking regressions by
visualizing the
service_timeof thewait-for-snapshotstask.This PR depends uses the Rally operation
wait-current-snapshots-createoperation (introduced inelastic/rally#1542).