Skip to content
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

Merged

Conversation

petermattis
Copy link
Collaborator

Release note: None

@cockroach-teamcity
Copy link
Member

This change is Reviewable

@petermattis
Copy link
Collaborator Author

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.

@nvanbenschoten
Copy link
Member

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

newOrder=45,payment=43,orderStatus=4,delivery=4,stockLevel=4

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 worker.go. The max tpmC rate then appears as the runtime of each txn approaches 0.

num workers per warehouse = 10
"decks" per worker = 1
new order txns complete in a deck = 45
time to complete all txns in a deck = 45*(18+12) + 43*(3+12) + 4*(2+10) + 4*(2+5) + 4*(2+5) = 2099 seconds

new order txns complete per warehouse per time = 10 * 45 / (2099 / 60) = 12.8632 tpmC per warehouse

@nvanbenschoten
Copy link
Member

Our default is actually a little bit different than this.

Was the point to reduce the variance in results for tests shorter than the time it takes to complete a single deck (~35 minutes)?

@jordanlewis
Copy link
Member

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.

image

Copy link
Collaborator Author

@petermattis petermattis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: :shipit: 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?

Copy link
Member

@nvanbenschoten nvanbenschoten left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: :shipit: 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.

@petermattis petermattis force-pushed the pmattis/roachtest-tpcc-efficiency branch from 630cef4 to 4e95b23 Compare July 31, 2018 14:38
Copy link
Collaborator Author

@petermattis petermattis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: :shipit: 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 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.

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.

@jordanlewis
Copy link
Member

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.

@petermattis petermattis force-pushed the pmattis/roachtest-tpcc-efficiency branch from 4e95b23 to 3806193 Compare July 31, 2018 15:44
@petermattis petermattis changed the title The max tpmC rate is 12.86x the number of warehouses The max tpmC rate is 12.605x the number of warehouses Jul 31, 2018
@petermattis
Copy link
Collaborator Author

bors r=nvanbenschoten

craig bot pushed a commit that referenced this pull request Jul 31, 2018
28010: The max tpmC rate  is 12.605x the number of warehouses r=nvanbenschoten a=petermattis

Release note: None

Co-authored-by: Peter Mattis <petermattis@gmail.com>
@craig
Copy link
Contributor

craig bot commented Jul 31, 2018

Build succeeded

@craig craig bot merged commit 3806193 into cockroachdb:master Jul 31, 2018
@petermattis petermattis deleted the pmattis/roachtest-tpcc-efficiency branch July 31, 2018 16:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants