On 08/11/06, James Bull <[EMAIL PROTECTED]> wrote:
On 02/11/06, James Bull <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
