FutureQ - v0 - #25
Draft
hertzcodes wants to merge 57 commits into
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
hi ahmad we gotta talk about this.
the replication (raft) is vibe coded and i still haven't reviewed claude's code in details.
only the producers is implemented.
overall I could reach 30k/s write speed (with payloads varying between 0 to 2kb) on a single node with 200 concurrent requests. ( we must find good values for raft per workload though )
also the client is important ( the more concurrent requests the better speed ( because we will have less syncs on dragonboat's pipeline during the same time ))
on 3 node replicas it gives us way less ( around 8k ) with strong consistency.
it was all on localhost btw. so it's defo way less in production
i know it's pretty bad but this is the most durable thing with the least complexity. we might have to add batching, increase concurrency internally in the sdk we are going to write and also support no acks or async disk writes to increase the speed.
there's no batching. only single message acks (always acks) and syncs
we gotta decide how much performance and what features we want for V2.
I don't have any idea for the consumer part and the deletion of keys yet. also the guarantees we want to have on the delivery.
just take a look at it and tell me what you think.
I think using pebble is actually a good idea since dragonboat uses pebble itself underneath.