Extending jmeter

[James Bull <jb...@thoughtworks.com>]

I want to have a listener that will take a value say 10 for the sake of 
argument and divide it into ten
intervals 1,2,3,4,5,6,7,8,9,10 in this case. For each interval it will 
have a variable.

As j-meter runs it will perform comparisons. And increment the variable 
associated with the interval into which the response time falls.

This information could ultimately be graphed in the j-meter gui but for 
the time being I would be happy just to output these values to the log.

I thought I would try basing my code on the SimpleDataWriter which extends 
the AbstractVisualiser

My theory was that I would just be able to add a data structure and work 
my funky magic from the addSample method.

Unfortunately I have fallen at the first hurdle and have failed to make it 
appear in the gui. I have got a class BucketWriter which is based on 
simple datawriter (I changed the class name and put it in a different 
package) I added a System.out.println(); to the addSample method in the 
hope I would be able to see this and be sure everything was working and 
make progress from there.

As far as I can tell Abstract Visualiser is supposed to deal with getting 
things into the menu system with the getMenuCategories() method which is 
set to say this is a listener.

I put the jar file containing only my class file into the lib directory. 
Is the package name important? 

So I would be grateful to know 1) how to get the thing appearing and 2) is 
it a good idea.

The idea of course is to get an idea of the distribution of response times 
without storing vast amounts of data.

For 10 buckets I anticipate it ought to be pretty quick as we can put a 
value in a bucket with only three comparisons if we do a binary search.

Would it be a crazy idea to try this for 100 buckets thus ending up with 
100 values stored per test and 10 or so comparisons needed?

My thinking is it would not be a good idea to try to set the max value 
automatically as you would have to keep all the samples in memory which is 
clearly daft. So if you have specified a silly number and all you results 
are in the final bucket then you just  specify a bigger number and run the 
test again.

I also thought it might be a good idea to specify start and finish values 
rather than just an end value and assuming a start interval of 0-whatever.

Any comments welcome.

Thanks,

James

Re: Extending jmeter

[sebb <se...@gmail.com>]

On 08/11/06, James Bull <jb...@thoughtworks.com> wrote:
> On 02/11/06, James Bull <jb...@thoughtworks.com> wrote:
>
> >> I put the jar file containing only my class file into the lib
> directory.
> >> Is the package name important?
>
> >No, but the jar needs to be put into lib/ext, not lib.
>
> Thats done the job. Thankyou very much. I have now got a listener that
> writes the page time to the log file.
> I can see how to proceed from here.

Good.

> >Seems fine, but it might be useful to be able to have unequal bucket
> sizes.
>
> >> Would it be a crazy idea to try this for 100 buckets thus ending up
> with
> >> 100 values stored per test and 10 or so comparisons needed?
>
> >Should be OK, but needs to be tested...
>
> Absolutely. I was thinking that I would generate as much load as I could
> on a static page on my local machine with a fixed number of users and an
> aggregate listener.
> I would add in the new listener I have created and run the same test
> again. If I've done it right there shouldn't be a significant drop in
> performance.
> I could find the number of buckets at which the change in performance was
> > x% and hard code a limit for the number of buckets at that level.
>
> Do you have any opinion on an appropriate value for x?

Not sure what you mean by "change in performance" - but whatever value
is chosen is likely to be wrong for some test plans, so just make it
variable.

> >As mentioned above, I think it would be useful to have variable bucket
> sizes.
> I have been having a think about this.
>
> If I am correct then the reason you want a variable bucket size is so you
> can look at certain ranges in more (or less) detail. ie
>
> 0 - 0.1, 0.1 - 0.5, 0.5 - 0.75,   0.75-1.5 , 1.5 - 3, 3-6.

Yes.

> I also see some value in being able to have j-meter work out some auto
> ranges by specifying
> Start:
> End:
> No of intervals:

Agreed.

> This would be useful if you wanted more than a few intervals.
>
> I think both would be good. Do you agree?

Yes.

> I think te easiest way to specify the intervals manually is to have a
> simple table with the first value (0) filled in and you fill in the end
> value for each interval with it auto creating the next row in the table
> with your end value from the last row being the start value for this one.
> The final row would remain uncompleted. This would give you two catch all
> buckets at either end.

Surely one catchall, unless the first value is > 0 - times cannot be negative.

> I'm going to start with auto generated buckets and test it with various
> numbers. Then I will add in user specified bucket sizes with the info
> being written to the log and finally try to get the info into the gui.
>

Another approach might be to have a table of bucket numbers, and
specify the condition for a sample to be put into the bucket. This
would allow the commonest values to be listed first.

The condition could be a range, or one might allow it to be a function
(Javascript, Beanshell) that returns a bucket number. This would allow
the element to be generalised to count response codes, or some other
aspect of the response.

> James
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org

Re: Extending jmeter

[James Bull <jb...@thoughtworks.com>]

On 02/11/06, James Bull <jb...@thoughtworks.com> wrote:

>> I put the jar file containing only my class file into the lib 
directory.
>> Is the package name important?

>No, but the jar needs to be put into lib/ext, not lib.

Thats done the job. Thankyou very much. I have now got a listener that 
writes the page time to the log file.
I can see how to proceed from here.

>Seems fine, but it might be useful to be able to have unequal bucket 
sizes.

>> Would it be a crazy idea to try this for 100 buckets thus ending up 
with
>> 100 values stored per test and 10 or so comparisons needed?

>Should be OK, but needs to be tested...

Absolutely. I was thinking that I would generate as much load as I could 
on a static page on my local machine with a fixed number of users and an 
aggregate listener.
I would add in the new listener I have created and run the same test 
again. If I've done it right there shouldn't be a significant drop in 
performance.
I could find the number of buckets at which the change in performance was 
> x% and hard code a limit for the number of buckets at that level.

Do you have any opinion on an appropriate value for x?

>As mentioned above, I think it would be useful to have variable bucket 
sizes.
I have been having a think about this. 

If I am correct then the reason you want a variable bucket size is so you 
can look at certain ranges in more (or less) detail. ie 

0 - 0.1, 0.1 - 0.5, 0.5 - 0.75,   0.75-1.5 , 1.5 - 3, 3-6.

I also see some value in being able to have j-meter work out some auto 
ranges by specifying 
Start:
End:
No of intervals:

This would be useful if you wanted more than a few intervals.

I think both would be good. Do you agree?

I think te easiest way to specify the intervals manually is to have a 
simple table with the first value (0) filled in and you fill in the end 
value for each interval with it auto creating the next row in the table 
with your end value from the last row being the start value for this one. 
The final row would remain uncompleted. This would give you two catch all 
buckets at either end.

I'm going to start with auto generated buckets and test it with various 
numbers. Then I will add in user specified bucket sizes with the info 
being written to the log and finally try to get the info into the gui.

James

Re: Extending jmeter

[sebb <se...@gmail.com>]

On 02/11/06, James Bull <jb...@thoughtworks.com> wrote:
> I want to have a listener that will take a value say 10 for the sake of
> argument and divide it into ten
> intervals 1,2,3,4,5,6,7,8,9,10 in this case. For each interval it will
> have a variable.
>
> As j-meter runs it will perform comparisons. And increment the variable
> associated with the interval into which the response time falls.
>
> This information could ultimately be graphed in the j-meter gui but for
> the time being I would be happy just to output these values to the log.
>
> I thought I would try basing my code on the SimpleDataWriter which extends
> the AbstractVisualiser
>
> My theory was that I would just be able to add a data structure and work
> my funky magic from the addSample method.
>
> Unfortunately I have fallen at the first hurdle and have failed to make it
> appear in the gui. I have got a class BucketWriter which is based on
> simple datawriter (I changed the class name and put it in a different
> package) I added a System.out.println(); to the addSample method in the
> hope I would be able to see this and be sure everything was working and
> make progress from there.
>
> As far as I can tell Abstract Visualiser is supposed to deal with getting
> things into the menu system with the getMenuCategories() method which is
> set to say this is a listener.
>
> I put the jar file containing only my class file into the lib directory.
> Is the package name important?

No, but the jar needs to be put into lib/ext, not lib.

> So I would be grateful to know 1) how to get the thing appearing and 2) is
> it a good idea.

Seems fine, but it might be useful to be able to have unequal bucket sizes.

> The idea of course is to get an idea of the distribution of response times
> without storing vast amounts of data.
>
> For 10 buckets I anticipate it ought to be pretty quick as we can put a
> value in a bucket with only three comparisons if we do a binary search.
>
> Would it be a crazy idea to try this for 100 buckets thus ending up with
> 100 values stored per test and 10 or so comparisons needed?

Should be OK, but needs to be tested...

> My thinking is it would not be a good idea to try to set the max value
> automatically as you would have to keep all the samples in memory which is
> clearly daft. So if you have specified a silly number and all you results
> are in the final bucket then you just  specify a bigger number and run the
> test again.
>

Or have a catch-all for values larger than a certain amount.

> I also thought it might be a good idea to specify start and finish values
> rather than just an end value and assuming a start interval of 0-whatever.
>
> Any comments welcome.
>

As mentioned above, I think it would be useful to have variable bucket sizes.

> Thanks,
>
> James
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org