Improve scalability in common cases #5920
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
vlsi
force-pushed
the
scalability
branch
4 times, most recently
from
7fc279d to
fafb948
Compare
vlsi
commented
May 17, 2023
vlsi
force-pushed
the
scalability
branch
4 times, most recently
from
2fdad4b to
beacd35
Compare
vlsi
force-pushed
the
scalability
branch
5 times, most recently
from
9e48147 to
012a5fc
Compare
vlsi
added a commit
that referenced
this pull request
May 25, 2023
… as it was doing in 5.5 In fact, ThreadGroup elements are cloned for each thread, so they might need recoverRunningVersion. See #5920
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This is a set of fixes that address common synchronization issues in JMeter.
Motivation and Context
It would be nice if JMeter could generate high number of concurrent requests without blocking in cases like
TestBeanpropertiesThreadGroup.getName()->syncrhonized propMap.get("...")TOTALrow, so synchronizing on the countersBenchmarks
See benchmark in #5875 (comment)
Rampup 0 (e.g. to make all the threads produce load faster)
Java 17.0.17
Apple M1 Max (2 efficiency and 8 performance cores)
Apparently, 100 threads doing CPU-intensive tasks makes no sense for 10 core machine, but it improved as well.
Notable improvement comes when a thread acquires a synchrinization lock and it gets preempted from the execution. When that happens, the other threads can't proceed until the thread moves to CPU again.
It means even short-lived synchronized sections are harmful.
The PR makes many such cases impossible.