jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: Extending jmeter
Date Wed, 08 Nov 2006 14:01:50 GMT
On 08/11/06, James Bull <> wrote:
> On 02/11/06, James Bull <> 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?

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

> >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.

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:
For additional commands, e-mail:

View raw message