-
Notifications
You must be signed in to change notification settings - Fork 217
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cassandra performance: repair_id prepared statements against repair_id & cache sequence #95
Cassandra performance: repair_id prepared statements against repair_id & cache sequence #95
Conversation
b629e11
to
504e937
Compare
Preconditions.checkState(idValue < Long.MAX_VALUE); | ||
attempts++; | ||
if(10 <= attempts && 0 == attempts % 10){ | ||
LOG.warn("still cant find a new repairId after " + attempts + " attempts"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
of little concern. WARN is generally always enabled, and the frequency of this log line low.
Tested against creating (but not activating) a non-incremental repair with 1467 segments. Before there was 14179 cql requests, after the patch only 5915 cql requests. |
Preconditions.checkState(idValue < Long.MAX_VALUE); | ||
attempts++; | ||
if(10 <= attempts && 0 == attempts % 10){ | ||
LOG.warn("still cant find a new repairId after " + attempts + " attempts"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, merging. |
Use prepared statements against repair_id, and cache a floor for the sequence number to reduce lookups.
ref: #94