Filestore: Use binary search for sequence-from-timestamp lookups#7357
Filestore: Use binary search for sequence-from-timestamp lookups#7357neilalexander merged 2 commits intomainfrom
Conversation
| defer fs.Stop() | ||
|
|
||
| for range 4096 { | ||
| _, _, err := fs.StoreMsg("foo.bar", nil, []byte{1, 2, 3, 4, 5}, 0) |
There was a problem hiding this comment.
You could use StoreMsgRaw() and pass a timestamp, and avoid the time.Sleep() at the end of the loop.
There was a problem hiding this comment.
We don't really need to specify our own timestamps as even the nanosecond precision should be enough (the small block size ensures every message gets its own block), but good spot that I left the sleep in, I will remove it.
Signed-off-by: Neil Twigg <neil@nats.io>
neilalexander
force-pushed
the
neil/getseqfromtime
branch
from
7ca414b to
1b37a6b
Compare
|
Cool 😄 does a nats image is generated upon merging this? Where can I get it? |
|
If it's a Docker image you'd like to test, I can kick off an early rebuild of the nightly image? |
|
Yes, that would be awesome 🙏 |
|
No problem, the updated nightly has been pushed: https://hub.docker.com/r/synadia/nats-server/tags |
|
@neilalexander may I have an arm image? all our nats servers have Also would it be possible to cherrypick this fix into |
|
thanks @neilalexander !!! |
4 participants
This updates the filestore
GetSeqFromTimefunction to use a binary search, such that the computational complexity is more predictable. This closes #7352 and fixes #7353 as this is a more idiomatic approach.Beforehand, the benchmark was very fast for earlier timestamps (as expected with a linear scan) but comparatively glacial for later ones:
After the change, this is now more predictable in the entire range:
Signed-off-by: Neil Twigg neil@nats.io