-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
The max tpmC rate is 12.605x the number of warehouses #28010
The max tpmC rate is 12.605x the number of warehouses #28010
Conversation
Noticed this in passing. This is the number we used in the tpcc spreadsheet. I can't recall where the number comes from. Cc @arjunravinarayan and @jordanlewis for verification. |
The max tpmC rate comes from a combination of the number of workers per warehouse and the maximum fraction of the time that each worker can spend on newOrder txns given the default mix and the default keying and thinking times. The default mix is
Our default is actually a little bit different than this. I'm not sure why. @jordanlewis do you? The default keying and thinking times are in
|
Was the point to reduce the variance in results for tests shorter than the time it takes to complete a single deck (~35 minutes)? |
We use the "deck" method described in the following paragraph. There are 2 ways to regulate the mix that are permitted by the spec - one that requires a percentage-based method that's continually checked to ensure that the mix is meeting the spec, and a simpler one that takes a uniformly random pass through a deck of cards with 10 cards for each of the two common txns, and 1 each for the other three txns. |
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.
Reviewable status: complete! 0 of 0 LGTMs obtained
pkg/cmd/roachtest/tpcc.go, line 415 at r1 (raw file):
} // Determine the fraction of the maximum possible tpmC realized. maxTpmC := 12.86 * float64(warehouses)
So should this be 12.8632?
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.
Reviewable status: complete! 0 of 0 LGTMs obtained
pkg/cmd/roachtest/tpcc.go, line 415 at r1 (raw file):
Previously, petermattis (Peter Mattis) wrote…
So should this be 12.8632?
Given that out mix is newOrder=10,payment=10,orderStatus=1,delivery=1,stockLevel=1
, it should actually be somewhere around 12.605
. I don't have strong opinions though. We're already accepting some loss of precision to reduce the number of iterations of this search loop anyway.
630cef4
to
4e95b23
Compare
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.
Reviewable status: complete! 0 of 0 LGTMs obtained
pkg/cmd/roachtest/tpcc.go, line 415 at r1 (raw file):
Previously, nvanbenschoten (Nathan VanBenschoten) wrote…
Given that out mix is
newOrder=10,payment=10,orderStatus=1,delivery=1,stockLevel=1
, it should actually be somewhere around12.605
. I don't have strong opinions though. We're already accepting some loss of precision to reduce the number of iterations of this search loop anyway.
I agree that the loss of precision in the search loop likely overwhelms this. I switched to 12.605 and added a comment explaining how that number is derived.
It is sort of suspicious that our mix results in a lower max-tpmC than the default mix.
Yeah, but this is explicitly the mix that they recommend using. I don't really understand why they even mention the percentages-based mix when they also recommend the deck method which has slightly different resultant percentages. |
Release note: None
4e95b23
to
3806193
Compare
bors r=nvanbenschoten |
Build succeeded |
Release note: None