I've been using JMeter as a user quite a bit the past few weeks, and I've learned some
things
about it. One is that it's very tedious to use, and so a lot of my thoughts have to
do with
creating more powerful tools to manipulate test scripts. I think I'd like to
introduce the idea of
alternate ways to view a test plan, ala eclipse, so that different aspects of test
plan editing can
be brought to the forefront.
Remote testing needs to be revamped because it's pointless to have 10 remote machines
all
trying to stuff responses down the I/O throat of a single controlling machine - better
to have the
remote machines keep the responses till the end and not risk the accuracy of
throughput
measurements. Perhaps a simpler format can be created for remote testing whereby
during
the test only success/failure plus response time is sent to the controlling machine,
and
everything else waits to the end of the test.
I want test results categorized by test run, and not just as a list of sampleResults.
A set of
sample results has a metadata set that describes the test run, and JMeter should be
able to
use such metadata to potentially combine test run results and also display statistics
comparing two test runs (ie, graphing # users vs throughput).
Result files need to be abstract datasources with an interface that visualizers talk
to without
knowing whether the backing data is an XML file, a CSV file, a database, etc. Right
now,
JMeter knows how to write CSV files, but can't read them! A defined interface will
help us
modularize this code whereas currently it's mixed up with the code for reading and
writing test
plan files.
Visualizers should be able to output useful file types for distribution of results to
non-jmeter
users. HTML and PNG files, for instance. Some way of exporting the data to a format
that
can be easily posted.
I wanted to make JMeter single threaded with the new non-blocking IO packages, but I
don't
think this is feasible. It's possible to do if you can get access to the very sockets
that do the
communicating, but how will you get that for jdbc drivers? Even for HTTP, we'd have
to write
our own HTTP Client from which we could gain access to the socket being used and
control
the IO for it (or take the commons client and modify it so). Because to put it all in
a single
threaded model, we'd have to take control of the IO part, and force the samplers to
hand their
sockets to some central code that would take the socket, take the bytes the sampler
wants to
send, and it would hand back the return bytes plus timing info. It'd be nice, but I
don't think it's
feasible for most protocols.
JMeter needs to collect more data. Size of responses should be explicitly collected
to help
throughput calculations of the form bytes/second. Timing data should include a
latency
measurement in addition to the whole response time. Multiple SampleResponses need to
be
dealt with better - I'm thinking that instead of an API that looks like:
Sampler{
SampleResult sample();
}
We need one that's more based on a callback situation:
Sampler {
void sample(SendResultsHereService callback);
}
so that Samplers can send multiple results to the collector service. This would make
samplers more flexible for when scripting in python is allowed - to allow the adhoc
scripter to
push out sample results at any time during their script.
Given this, post-processors like assertions and post-processors need a way to know
which
result to apply themselves to. We already have this problem wherein redirected
samples
confuse these components. We need a way to either mark a particular response as "the
main
one" or define a response set all of which need to be tested by the applicable
post-processors.
I'd also like to replace the Avalon Configuration stuff with something that can load
files more
stream-like and piecemeal, instead of creating a DOM and then handing it over to
JMeter. It
goes too long without any feedback for the user. Plus uses a ton of memory.
Sun's HTTP Client should be replaced. As the cornerstone of JMeter, we ought to have
one
that is highly flexible to our needs, provides the most accurate timing it can, the
most
performance possible, the least resource intensive as possible, and the most
transparency to
JMeter's controlling code. I think the commons HTTP Client is probably a good place
to start,
being open-source, we can craft it to our needs.
Well, that's a start :-)
-Mike
On 11 Aug 2003 at 2:35, Jordi Salvat i Alabart wrote:
>
>
> [EMAIL PROTECTED] wrote:
> > I'm pretty committed to the idea that JMeter 2.0 will be drastically different
> > from JMeter
1.9.
> > So, feel free to make big changes.
>
> Hey, Mike, we'd like to know what you're thinking about?
>
> --
> Salut,
>
> Jordi.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
--
Michael Stover
[EMAIL PROTECTED]
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
