You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jmeter-dev@jakarta.apache.org by Jeremy Arnold <je...@bigfoot.com> on 2003/02/24 13:37:50 UTC
Extra fields in SampleResult
Hello,
After travelling, recovering from a cold, and catching up after the
above, I'm ready to tackle a couple more JMeter patches. But I've got a
couple of questions before I put the finishing touches on the patches
and send them in.
The goal of the first patch is to reduce the size of SampleResult
objects. There are a couple of unused fields, and some other fields
which are sometimes used but take up a fair amount of memory even in
cases where they are not being used. I would like to fix these to
reduce memory usage and improve the serialization of these objects.
1) The "map" and "mark" fields don't appear to be used at all. I plan
to get rid of these completely.
2) "assertionResults", "subResults", and "files" can be used in some
cases, but not always. Instead of instantiating these fields
immediately, I plan to use lazy instantiation to create the List/Set
objects only when they are actually needed.
3) If we use lazy instantiation for these fields, should the
corresponding "get" methods return null if the fields haven't been set?
Or should they return an empty List/Set? I would prefer null, but the
calling code has to be able to handle this. I can make sure that any
calling code in JMeter will handle this properly, but this change could
break any user-written code that might rely on getting back a non-null
reference. So maybe it would be better to return an empty List/Set for
now, and then next time we have a significant API change we can make
this change as well.
4) Today's SampleResult isn't thread-safe, so I assume my new
modifications don't have to be thread-safe either. I haven't studied
the code enough to determine whether or not JMeter allows SampleResult
to be accessed concurrently by more than one thread. My lazy
instantiation code will probably be less thread-safe than the existing
code, so it could possibly break something that works today. I can make
it thread-safe if it needs to be, but I won't add the extra overhead if
it's not necessary.
I think that's it. If you have any questions, let me know.
Otherwise, I should have a patch ready soon after I get a thumbs-up on
the above.
Jeremy
http://www.xirr.com/~jeremy_a
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Extra fields in SampleResult
Posted by Jordi Salvat i Alabart <js...@atg.com>.
Mike Stover wrote:
> Yeah, the Sampler does the work, and copies data from config objects into itself. This could
> probably fixed by instead having the sampler hold config objects and delegate to them in the
> event of null properties. Then, after the sample run, the sampler can simply discard the
> delegates.
So, we DO have solutions in case we decide cloning is an issue... we
just need to run some performance testing to determine this :-)
BTW, I'm trying to track Oliver's work, but it's often too clever for me
to follow without help. Oliver: a word or two from time to time on what
you're on would be greatly appreciated.
Salut,
Jordi.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Extra fields in SampleResult
Posted by Mike Stover <ms...@apache.org>.
On 25 Feb 2003 at 1:01, Jordi Salvat i Alabart wrote:
>
> > I liked the idea of official "Property" objects from Oliver. I think it's a rather big task though,
> > and complicated.
>
> Have I missed that discussion? Or are you refering to "the use of
> special property objects" mentioned in
> http://nagoya.apache.org/wiki/apachewiki.cgi?JMeterArchitecturalOverview ?
Well, there aren't many specifics there, and I haven't looked at Oliver's code myself. I think
the idea is to encapsulate some useful functionality in a Property hierarchy - with
StringProperty, IntegerProperty, CollectionProperty, etc. Then, when grabbing data from a
TestElement, the Property object can arrange to deliver functions correctly, etc.
It would have a lot of advantages in terms of code consistency, facilitating functions, making
the .jmx files very "regular". It would have the disadvantage of making for a lot of verbose
code, and affecting lots of classes.
>
> Or should I go straight to Oliver's code?
It's probably worth a look.
>
> >
> > Also, there's another case I forgot - and the real reason Samplers are PerSampleClonable:
> > Default config objects - they write into the Samplers, but you don't want that to become part of
> > the Sampler permanently. Of course, I can think of some interesting ways to deal with that
> > too...
>
> Is it that way? I thought it was the sampler knowing about the config
> object, not the reverse. Maybe I should revisit those Wiki pages on
> JMeter internals w.r.t. configs...
Yeah, the Sampler does the work, and copies data from config objects into itself. This could
probably fixed by instead having the sampler hold config objects and delegate to them in the
event of null properties. Then, after the sample run, the sampler can simply discard the
delegates.
-Mike
>
> Salut,
>
> Jordi.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: how to specify sample listener in plan
Posted by Richard Han <ha...@shaw.ca>.
It works if I just add the following to the plan
<node>
<testelement class="org.apache.jmeter.reporters.MyListener">
<property xml:space="preserve"
name="TestElement.test_class">org.apache.jmeter.reporters.MyListener</proper
ty>
</testelement>
</node>
----- Original Message -----
From: "Richard Han" <ha...@shaw.ca>
To: "JMeter Developers List" <jm...@jakarta.apache.org>
Sent: Monday, February 24, 2003 9:43 PM
Subject: how to specify sample listener in plan
> Hi,
> Please help me if you could.
>
> I am trying to let the test do something when the sampling is done. I am
> thinking writing an SampleListener, i.e.,
>
> class MySampleListener implements SampleListener
> {
> public void sampleOccurred(SampleEvent sampleEvent)
> {
> doSomething()
> }
> etc etc
> }
>
>
> but I don't know how to specify my SampleListener in the test plan.
> BTW I don't need any Visualizers because I am running JMeter in non-gui
> mode.
> I am using JMeter-1.8.1
>
> Thanks in advance!
>
> richard
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
how to specify sample listener in plan
Posted by Richard Han <ha...@shaw.ca>.
Hi,
Please help me if you could.
I am trying to let the test do something when the sampling is done. I am
thinking writing an SampleListener, i.e.,
class MySampleListener implements SampleListener
{
public void sampleOccurred(SampleEvent sampleEvent)
{
doSomething()
}
etc etc
}
but I don't know how to specify my SampleListener in the test plan.
BTW I don't need any Visualizers because I am running JMeter in non-gui
mode.
I am using JMeter-1.8.1
Thanks in advance!
richard
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Extra fields in SampleResult
Posted by Jordi Salvat i Alabart <js...@atg.com>.
> I liked the idea of official "Property" objects from Oliver. I think it's a rather big task though,
> and complicated.
Have I missed that discussion? Or are you refering to "the use of
special property objects" mentioned in
http://nagoya.apache.org/wiki/apachewiki.cgi?JMeterArchitecturalOverview ?
Or should I go straight to Oliver's code?
>
> Also, there's another case I forgot - and the real reason Samplers are PerSampleClonable:
> Default config objects - they write into the Samplers, but you don't want that to become part of
> the Sampler permanently. Of course, I can think of some interesting ways to deal with that
> too...
Is it that way? I thought it was the sampler knowing about the config
object, not the reverse. Maybe I should revisit those Wiki pages on
JMeter internals w.r.t. configs...
Salut,
Jordi.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Extra fields in SampleResult
Posted by Mike Stover <ms...@apache.org>.
The problem isn't the speed of the functions (they can easily cache their results). the problem
is figuring out a good way to make all the code smart enough to grab the function and tell it to
yield a result. Right now, most code expects strings to be held as TestElement properties. Not
so hard to change that. However, some TestElements hold collections, which are often
expected to hold strings, but could be functions. Without detailing a clever way of handling
the functions, all JMeter code would be forced to examine every "String" property retrieved
from anywhere in a TestElement and ask it if it's a function, and if so, execute it. And then,
only when in the context of a running test.
I liked the idea of official "Property" objects from Oliver. I think it's a rather big task though,
and complicated.
Also, there's another case I forgot - and the real reason Samplers are PerSampleClonable:
Default config objects - they write into the Samplers, but you don't want that to become part of
the Sampler permanently. Of course, I can think of some interesting ways to deal with that
too...
I suspect you're right about the value of an object pool in this case. I think the number of
TestElements created may be dwarfed by the number of strings and other objects created
from cloning.
-Mike
On 24 Feb 2003 at 17:56, Jordi Salvat i Alabart wrote:
> My experience using pools to avoid allocations is very varied. Many
> times they don't really improve overall performance much (the cost of
> keeping the pool and cleaning up after usage is too close to that of
> allocating and collecting garbage). I've seen cases (bad
> implementations) where they degrade performance significantly.
> Complexity always grows.
>
> I'd definitely favour more restraint in using PerSampleClonable.
>
> Maybe the function-caused cloning could be reexamined, too? What's the
> cost of re-evaluating a function? Looks like most functions are pretty
> simple (actually all but the regexp ones). How often is a property of a
> test element used twice, effectively obtaining a gain from this
> "function result caching" feature? Could we require functions to be fast
> (maybe by caching their own results) instead? Or maybe we could keep
> variables and remove functions proper, moving necessary calculations to
> pre/post-processors?
>
> Well... just popping out ideas. I think it's too early for such drastic
> changes. We need some real performance analysis first.
>
> Salut,
>
> Jordi.
>
> Mike Stover wrote:
> > On 24 Feb 2003 at 17:13, Jordi Salvat i Alabart wrote:
> >
> >
> >>What about only cloning the elements when we actually need to modify
> >>them? Or even just agree to never modify them and store the "variable"
> >>data in the result instead?
> >
> >
> > For the most part, this is what happens. TestElements are only cloned in three
> > cases:
> >
> > 1. If they implement PerThreadClonable. Not really a problem since it's obviously
> > necessary for those that do it, and it all happens before the threads start.
> > 2. If they have functions that get replaced with real-time values during test runs.
> > In this case, they get cloned at the time that their functions get replaced.
> > 3. If they implement PerSampleClonable. There's probably some wiggle room here
> > since AbstractSampler extends PerSampleClonable perhaps unnecessarily - most
> > samplers could probably be written so as not to modify themselves.
> >
> > In any case, that still leaves a lot of cloning going on. A pool of test element
> > objects would probably still help
> >
> > -Mike
> >
> >
> >>Mike Stover wrote:
> >>
> >>>>A related issue is all that cloning (of test elements) that's happening
> >>>>behind the scenes. I've not yet had time to actually measure, but I have
> >>>>a feeling that it is tremendously expensive -- not the cloning itself,
> >>>>but cleaning up all the garbage afterwards. Anyone got figures?
> >>>
> >>>
> >>>It's occurred to me on more than one occasion that JMeter could use a TestElement
> >>>pool that creates objects as needed, or provides currently unused blank objects. It
> >>>would require changes to code so that TestElements are returned to the pool when
> >>>done, but it would probably be worth it.
> >>>
> >>>-Mike
> >>>
> >>>
> >>>
> >>>>Salut,
> >>>>
> >>>>Jordi.
> >>>>
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> >>>>For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>--
> >>>Michael Stover
> >>>mstover1@apache.org
> >>>Yahoo IM: mstover_ya
> >>>ICQ: 152975688
> >>>AIM: mstover777
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >>>
> >>>
> >>
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >>
> >
> >
> >
> >
> > --
> > Michael Stover
> > mstover1@apache.org
> > Yahoo IM: mstover_ya
> > ICQ: 152975688
> > AIM: mstover777
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Extra fields in SampleResult
Posted by Jordi Salvat i Alabart <js...@atg.com>.
My experience using pools to avoid allocations is very varied. Many
times they don't really improve overall performance much (the cost of
keeping the pool and cleaning up after usage is too close to that of
allocating and collecting garbage). I've seen cases (bad
implementations) where they degrade performance significantly.
Complexity always grows.
I'd definitely favour more restraint in using PerSampleClonable.
Maybe the function-caused cloning could be reexamined, too? What's the
cost of re-evaluating a function? Looks like most functions are pretty
simple (actually all but the regexp ones). How often is a property of a
test element used twice, effectively obtaining a gain from this
"function result caching" feature? Could we require functions to be fast
(maybe by caching their own results) instead? Or maybe we could keep
variables and remove functions proper, moving necessary calculations to
pre/post-processors?
Well... just popping out ideas. I think it's too early for such drastic
changes. We need some real performance analysis first.
Salut,
Jordi.
Mike Stover wrote:
> On 24 Feb 2003 at 17:13, Jordi Salvat i Alabart wrote:
>
>
>>What about only cloning the elements when we actually need to modify
>>them? Or even just agree to never modify them and store the "variable"
>>data in the result instead?
>
>
> For the most part, this is what happens. TestElements are only cloned in three
> cases:
>
> 1. If they implement PerThreadClonable. Not really a problem since it's obviously
> necessary for those that do it, and it all happens before the threads start.
> 2. If they have functions that get replaced with real-time values during test runs.
> In this case, they get cloned at the time that their functions get replaced.
> 3. If they implement PerSampleClonable. There's probably some wiggle room here
> since AbstractSampler extends PerSampleClonable perhaps unnecessarily - most
> samplers could probably be written so as not to modify themselves.
>
> In any case, that still leaves a lot of cloning going on. A pool of test element
> objects would probably still help
>
> -Mike
>
>
>>Mike Stover wrote:
>>
>>>>A related issue is all that cloning (of test elements) that's happening
>>>>behind the scenes. I've not yet had time to actually measure, but I have
>>>>a feeling that it is tremendously expensive -- not the cloning itself,
>>>>but cleaning up all the garbage afterwards. Anyone got figures?
>>>
>>>
>>>It's occurred to me on more than one occasion that JMeter could use a TestElement
>>>pool that creates objects as needed, or provides currently unused blank objects. It
>>>would require changes to code so that TestElements are returned to the pool when
>>>done, but it would probably be worth it.
>>>
>>>-Mike
>>>
>>>
>>>
>>>>Salut,
>>>>
>>>>Jordi.
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>>>>
>>>
>>>
>>>
>>>
>>>--
>>>Michael Stover
>>>mstover1@apache.org
>>>Yahoo IM: mstover_ya
>>>ICQ: 152975688
>>>AIM: mstover777
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>>
>
>
>
>
> --
> Michael Stover
> mstover1@apache.org
> Yahoo IM: mstover_ya
> ICQ: 152975688
> AIM: mstover777
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Extra fields in SampleResult
Posted by Mike Stover <ms...@apache.org>.
On 24 Feb 2003 at 17:13, Jordi Salvat i Alabart wrote:
> What about only cloning the elements when we actually need to modify
> them? Or even just agree to never modify them and store the "variable"
> data in the result instead?
For the most part, this is what happens. TestElements are only cloned in three
cases:
1. If they implement PerThreadClonable. Not really a problem since it's obviously
necessary for those that do it, and it all happens before the threads start.
2. If they have functions that get replaced with real-time values during test runs.
In this case, they get cloned at the time that their functions get replaced.
3. If they implement PerSampleClonable. There's probably some wiggle room here
since AbstractSampler extends PerSampleClonable perhaps unnecessarily - most
samplers could probably be written so as not to modify themselves.
In any case, that still leaves a lot of cloning going on. A pool of test element
objects would probably still help
-Mike
>
> Mike Stover wrote:
> >>A related issue is all that cloning (of test elements) that's happening
> >>behind the scenes. I've not yet had time to actually measure, but I have
> >>a feeling that it is tremendously expensive -- not the cloning itself,
> >>but cleaning up all the garbage afterwards. Anyone got figures?
> >
> >
> > It's occurred to me on more than one occasion that JMeter could use a TestElement
> > pool that creates objects as needed, or provides currently unused blank objects. It
> > would require changes to code so that TestElements are returned to the pool when
> > done, but it would probably be worth it.
> >
> > -Mike
> >
> >
> >>Salut,
> >>
> >>Jordi.
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >>
> >
> >
> >
> >
> > --
> > Michael Stover
> > mstover1@apache.org
> > Yahoo IM: mstover_ya
> > ICQ: 152975688
> > AIM: mstover777
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Extra fields in SampleResult
Posted by Jordi Salvat i Alabart <js...@atg.com>.
What about only cloning the elements when we actually need to modify
them? Or even just agree to never modify them and store the "variable"
data in the result instead?
Mike Stover wrote:
>>A related issue is all that cloning (of test elements) that's happening
>>behind the scenes. I've not yet had time to actually measure, but I have
>>a feeling that it is tremendously expensive -- not the cloning itself,
>>but cleaning up all the garbage afterwards. Anyone got figures?
>
>
> It's occurred to me on more than one occasion that JMeter could use a TestElement
> pool that creates objects as needed, or provides currently unused blank objects. It
> would require changes to code so that TestElements are returned to the pool when
> done, but it would probably be worth it.
>
> -Mike
>
>
>>Salut,
>>
>>Jordi.
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>>
>
>
>
>
> --
> Michael Stover
> mstover1@apache.org
> Yahoo IM: mstover_ya
> ICQ: 152975688
> AIM: mstover777
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Extra fields in SampleResult
Posted by Mike Stover <ms...@apache.org>.
> A related issue is all that cloning (of test elements) that's happening
> behind the scenes. I've not yet had time to actually measure, but I have
> a feeling that it is tremendously expensive -- not the cloning itself,
> but cleaning up all the garbage afterwards. Anyone got figures?
It's occurred to me on more than one occasion that JMeter could use a TestElement
pool that creates objects as needed, or provides currently unused blank objects. It
would require changes to code so that TestElements are returned to the pool when
done, but it would probably be worth it.
-Mike
>
> Salut,
>
> Jordi.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Extra fields in SampleResult
Posted by Jordi Salvat i Alabart <js...@atg.com>.
> 3) If we use lazy instantiation for these fields, should the
> corresponding "get" methods return null if the fields haven't been set?
> Or should they return an empty List/Set? I would prefer null, but the
> calling code has to be able to handle this. I can make sure that any
> calling code in JMeter will handle this properly, but this change could
> break any user-written code that might rely on getting back a non-null
> reference. So maybe it would be better to return an empty List/Set for
> now, and then next time we have a significant API change we can make
> this change as well.
I'm for null. User-written code shouldn't be a concern here. We're on a
"major development" phase now. If it's user-written, it can be
user-fixed, too, can't it? If you introduce new bugs... well... we'll
fix them.
Could be a good idea to do a quick review of all code calling those
methods and ascertain how it will behave.
> 4) Today's SampleResult isn't thread-safe, so I assume my new
> modifications don't have to be thread-safe either. I haven't studied
> the code enough to determine whether or not JMeter allows SampleResult
> to be accessed concurrently by more than one thread.
SampleResults are designed to be created and populated by one single
thread. Once this has happened, other threads may access them, but
read-only, so it shouldn't be a problem.
> My lazy
> instantiation code will probably be less thread-safe than the existing
> code, so it could possibly break something that works today. I can make
> it thread-safe if it needs to be, but I won't add the extra overhead if
> it's not necessary.
Go for it. Performance and heap memory usage is one of the big problems
of JMeter now, so any step we take to improve that is very welcome.
A related issue is all that cloning (of test elements) that's happening
behind the scenes. I've not yet had time to actually measure, but I have
a feeling that it is tremendously expensive -- not the cloning itself,
but cleaning up all the garbage afterwards. Anyone got figures?
Salut,
Jordi.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Extra fields in SampleResult
Posted by Mike Stover <ms...@apache.org>.
On 24 Feb 2003 at 13:37, Jeremy Arnold wrote:
> Hello,
> After travelling, recovering from a cold, and catching up after the
> above, I'm ready to tackle a couple more JMeter patches. But I've got a
> couple of questions before I put the finishing touches on the patches
> and send them in.
>
> The goal of the first patch is to reduce the size of SampleResult
> objects. There are a couple of unused fields, and some other fields
> which are sometimes used but take up a fair amount of memory even in
> cases where they are not being used. I would like to fix these to
> reduce memory usage and improve the serialization of these objects.
>
> 1) The "map" and "mark" fields don't appear to be used at all. I plan
> to get rid of these completely.
Not sure what you mean by "get rid of". If you mean "prevent from being written to file", that's
probably fine. The mark field is used, however in the SamplerResult object. It's the
ResultCollector's way of knowing whether it has already recorded a particular sample. If two
listeners are pointed at the same output file, you will not get duplicates or any other corruption
of your data during test run and recording.
I honestly don't even remember what "map" might be, so who knows?
>
> 2) "assertionResults", "subResults", and "files" can be used in some
> cases, but not always. Instead of instantiating these fields
> immediately, I plan to use lazy instantiation to create the List/Set
> objects only when they are actually needed.
Sounds fine.
>
> 3) If we use lazy instantiation for these fields, should the
> corresponding "get" methods return null if the fields haven't been set?
> Or should they return an empty List/Set? I would prefer null, but the
> calling code has to be able to handle this. I can make sure that any
> calling code in JMeter will handle this properly, but this change could
> break any user-written code that might rely on getting back a non-null
> reference. So maybe it would be better to return an empty List/Set for
> now, and then next time we have a significant API change we can make
> this change as well.
I don't mind null, but it needs to be documented somewhere - put it in the javadocs for now.
>
> 4) Today's SampleResult isn't thread-safe, so I assume my new
> modifications don't have to be thread-safe either. I haven't studied
> the code enough to determine whether or not JMeter allows SampleResult
> to be accessed concurrently by more than one thread. My lazy
> instantiation code will probably be less thread-safe than the existing
> code, so it could possibly break something that works today. I can make
> it thread-safe if it needs to be, but I won't add the extra overhead if
> it's not necessary.
SampleResult shouldn't need to be threadsafe. A sampleResult is created by one thread, and
passed to the listener. Only one thread at a time has access to the object.
>
> I think that's it. If you have any questions, let me know.
> Otherwise, I should have a patch ready soon after I get a thumbs-up on
> the above.
Looking forward to it!
-Mike
>
> Jeremy
> http://www.xirr.com/~jeremy_a
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
--
Michael Stover
mstover1@apache.org
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org