You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 22, 2023. It is now read-only.
Right now keys to read are generated on random (random seed is const, so the problem is a bit theoretical) and it means the generated key may not exist. We should rather generate keys based on a list of existing keys (previously inserted).
It may not be trivial for benchmarks doing reads and writes simultaneously (like readrandomwriterandom).
And we have to do this will little-to-no impact on performance measurements.
We could also introduce a way to parametrize how many keys should exist (something like hit/miss ratio).
Rationale
We could test hit/miss rates on key reads. E.g. see different behavior for db performance, which returns NOT_FOUND / OK statuses in different ratios.
Sometimes it's required to read existing keys, otherwise the measurements may be e.g. unexpectedly high.
API Changes
rather no
perhaps a new benchmark type or new input parameter will be provided along this change
Implementation details
TBD
The text was updated successfully, but these errors were encountered:
Description
Right now keys to read are generated on random (random seed is const, so the problem is a bit theoretical) and it means the generated key may not exist. We should rather generate keys based on a list of existing keys (previously inserted).
It may not be trivial for benchmarks doing reads and writes simultaneously (like readrandomwriterandom).
And we have to do this will little-to-no impact on performance measurements.
We could also introduce a way to parametrize how many keys should exist (something like hit/miss ratio).
Rationale
We could test hit/miss rates on key reads. E.g. see different behavior for db performance, which returns NOT_FOUND / OK statuses in different ratios.
Sometimes it's required to read existing keys, otherwise the measurements may be e.g. unexpectedly high.
API Changes
rather no
perhaps a new benchmark type or new input parameter will be provided along this change
Implementation details
TBD
The text was updated successfully, but these errors were encountered: