jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Sitnikov <sitnikov.vladi...@gmail.com>
Subject NoThreadClone should be used more often
Date Sun, 29 Mar 2020 10:13:42 GMT
Hi,

I've noticed that we have just a few cases when NoThreadClone is used.
It results in enormous memory consumption since the test plan is
effectively duplicated for each and every thread.

Just in case: my testcase is 1 thread group (100'000 threads), 10
transaction controllers (each has one FlowControlAction, and one Constant
30sec timer).
The test does not fit within 2Gb RAM :-(


AFAIK there are three types of elements:
* (almost) Stateless. For instance, UniformRandomTimer has no fields, and
it does not even access its own properties.
Note: there's `getRandom()` which is now implemented as
`ThreadLocalRandom.current()` so it is thread-safe
* Semi-stateless. For instance, TestAction. It does have a state for
cancellation purposes (it needs to remember which thread to cancel)
* Elements that do hold state. For example, TransactionController has quite
a few fields

I think we should do something with that, otherwise, the memory consumption
is insane.

I see the following possibilities:
a) Implement copy-on-write like mode for properties.
For instance, we can add `modifiedPropMap` for the properties that were
modified in the running version.
Then we could share the same property map and newly modified properties (if
any) would go another map.
That would save a lot of memory by small changes to the core alone.

Just some numbers:
400'000 TestActions retain 315MiB in the heap, and the most part of it
(300MiB) is consumed by property maps

b) Apply NoThreadClone when possible. Note: `NoThreadClone` interface
propagates for the derived classes,
however, it might be the case that the derived class does have state, thus
it requires cloning.
So I think we might need to add `@ThreadClone` annotation which would
enable us to specify different cloning behaviors for parent and derived
classes.

Then we might want to add a test case that ensures all in-core components
either support NoThreadClone or explicitly declare that they do not support
it.

c) Consider dropping some attributes when making a runtime version.
For instance, TestAction has the following properties:
ActionProcessor.action
ActionProcessor.duration
ActionProcessor.target
TestElement.enabled
TestElement.gui_class
TestElement.name
TestElement.test_class
TestElement.comments

I guess gui_class and test_class are not really required for the running
version.
It might play well with annotation:
`@ThreadClone(excludeProperties=["...gui_class", "test_class"])`

Any thoughts?

Vladimir

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message