-
Notifications
You must be signed in to change notification settings - Fork 0
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
[JFG-833] New implementation of RPS load with periodic workload process. #581
Conversation
PerThreadWorkloadProcess remains the same (not using AbstractWorkloadProcess) by purpose. |
d6624c6
to
4bf9c72
Compare
…orkload services done.
this(DEFAULT_CORE_POOL_SIZE); | ||
} | ||
|
||
public PeriodSingleTaskScheduler(int corePoolSize) { |
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.
for what purposes you need corePoolSize ?
New implementation of RPS load with periodic workload process.
// wait till execution stops | ||
lfs.get(); | ||
} catch (InterruptedException e) { | ||
e.printStackTrace(); |
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.
WAT?
any tests? schema changes? |
There is one new test in smokes, and there are more tests in separate repo : https://github.com/amikryukov/qps-test-temporary |
is new test uses periodic workload? |
Yes - actually now, all tests that uses "rps-load" - uses periodic workload, as from now on "rps-load" is parsed as new clock configuration, witch send "period" in configuration to Kernels(Workers) while ticking. And that is the way workload branch is choosing: if (command.getScenarioContext().getWorkloadConfiguration().getPeriod() > 0) { |
Invocations starts with calculated period.
If thread pull is full (not enough threads to provide specified rps) - WARN message occurs.