-
Notifications
You must be signed in to change notification settings - Fork 101
feature(perf): support latte in gradual grow throughput test #10901
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
base: master
Are you sure you want to change the base?
feature(perf): support latte in gradual grow throughput test #10901
Conversation
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.
Pull Request Overview
This PR introduces support for the Latte benchmarking tool in the gradual throughput tests by parsing its unique command line options for threads and rate.
- Added a regex-based function to extract latte thread parameters.
- Introduced a helper function to adjust the CS thread count based on latte threads.
- Updated throttle formatting logic to distinguish between Latte and legacy CS commands.
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
File | Description |
---|---|
sdcm/stress/latte_thread.py | Added regex and extraction function to determine Latte's thread count. |
performance_regression_gradual_grow_throughput.py | Integrated Latte thread count logic and updated throttle handling in test steps. |
d121a79
to
8802a35
Compare
Tested here: scylla-staging/valerii/vp-perf-regression-predefined-throughput-steps-rust-vnodes#11 Reason for the changes is here: https://github.com/scylladb/qa-tasks/issues/1659 |
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.
IIUC currently, still user needs to watch how many CPUs loaders have.
for me, the ultimate solution would be to introduce 'latte_cs_thread' that could parse prefixed by latte
c-s command like: latte <full cassandra stress command>
This way, the thread could take proper rune scripts, translate c-s command to latte one and we wouldn't have to learn new syntax for running tests with latte (when need c-s like workload). WDYT?
It is only about efficiency. And it is very easy. Instance type is known, CPU core count is known, do (n - 1) for high rate commands.
It will limit all the flexibility latte provides.
Each separate rune script has unique set of parameters for schema creation and for queries.
Parsing of CS command into latte is not really good idea for performance scenarios. And, anyway, potential feature of parsing CS into latte should be a separate PR. |
8802a35
to
76f3804
Compare
Gradual throughput test uses several substitution variables and 2 of them, called "$threads" and "$throttle", are not compatible "as-is" with the latte benchmarking tool. First, Latte has "--threads=N" and "--concurrency=M" parameters whereas cassandra-stress has only "--threads". So, latte's values must be multiplied to get CS's value. Second, latte uses "--rate=100" not "fixed=100/s" or "throttle=100s" like CS does. Knowing above, add appropriate parsing of the latte command to support existing substitution values. Example: Following CS command: cassandra-stress mixed cl=QUORUM duration=$duration -mode cql3 native \ -rate 'threads=$threads $throttle' \ -col 'size=FIXED(1024) n=FIXED(1)' -pop seq=15000001..20000000 Can be simulated by the following Latte command: latte run --function=write,read --tag=mixed --sampling=10s --duration=$duration \ $throttle --threads=7 --concurrency=$threads --consistency=QUORUM --start-cycle 15000001 --end-cycle 20000000 \ -P key_size=10 -P column_size=1024 -P column_count=1 -P row_count=20000000 data_dir/latte/latte_cs_alike.rn In case of Latte we specify "--threads" explicitly as (N-1) value where N is number of CPU cores on loader nodes.
76f3804
to
f3ff8bd
Compare
Sorry for the late reply,
I'm not saying to replace
That's the hard part (at the beginning) and this could alleviate it. People don't know how things work in latte and need some learning to use it properly.
|
This computation is made just to keep compatibility with existing interfaces for configuration. Then, we can update the number of CS threads which get considered in calculation for latte configurations.
I don't mind to have such a wrapper, just not in scope of this PR.
As said above, I am ok to have just in a separate task/PR. |
Gradual throughput test uses several substitution variables and 2 of them,
called
$threads
and$throttle
, are not compatibleas-is
with the latte benchmarking tool.First, Latte has
--threads=N
and--concurrency=M
parameterswhereas cassandra-stress has only
--threads
.So, latte's values must be multiplied to get CS's value.
Second, latte uses
--rate=100
format notfixed=100/s
orthrottle=100s
like CS does.Knowing above, add appropriate parsing of the latte commands
to support existing substitution values.
Example:
Following CS command:
Can be simulated by the following Latte command:
In case of Latte we specify
--threads
explicitly as(N-1)
value whereN
is number of CPU cores on loader nodes.Testing
PR pre-checks (self review)
backport
labelsReminders
sdcm/sct_config.py
)unit-test/
folder)