-
Notifications
You must be signed in to change notification settings - Fork 9.7k
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
server: set multiple concurrentReadTx instances share one txReadBuffer. Approach #2 #12935
Conversation
This is a patch inspired by #12529 |
e215853
to
9d5be87
Compare
Codecov Report
@@ Coverage Diff @@
## master #12935 +/- ##
==========================================
- Coverage 73.31% 72.97% -0.35%
==========================================
Files 430 430
Lines 34182 34676 +494
==========================================
+ Hits 25060 25304 +244
- Misses 7194 7393 +199
- Partials 1928 1979 +51
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
I am going to run a performance evaluation of this patch later. |
…r. Regenerate a cache each time after writeback()
9d5be87
to
d422795
Compare
Never mind about this patch. Its initial performance is horrible. |
This is a different approach for the similar issue trying to resolve in #12933
Currently, the concurrentReadTx does a copy of the txReadBuffer inside backend readTx. However, this buffer is never modified by concurrentReadTx. Therefore, we can just use a single copy of the txReadBuffer as long as there are no new changes committed to backend DB.
Therefore, we use a cached txReadBuffer to avoid excessive deep copy operations for the new read transaction.