Re: jMeter development project inquiry

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

It's already possible to run multiple JMX files in GUI mode (though
not automatically), and the server in client-server mode can be left
running between test runs, so that Java startup-time is restricted to
the client.

Batch mode only processes the single jmx file provided on the command-line.

I'm sure it would be to extend JMeter as proposed.
However the proposal requires an extra process to send the JMX data
and to receive the results, both of which add extra overhead.

Perhaps it would be simpler to implement an option to process all JMX
files in a directory, or listed in a file.

JMeter startup does not take very long (around 1 sec on my system) so
the proposed change would only benefit test runs with lots of
independent tests.

On 21/12/2007, Pieter Ennes <pi...@watchmouse.com> wrote:
> Dear jMeter list,  (-user list included due to amount of commit
> msgs on -dev, followup set to -dev)
>
> We are using jMeter to perform conformance and regression tests
> periodically (typically every 15 minutes, for a large number of tests),
> and are looking for ways to push integration a bit further. We are
> investigating whether it is possible to develop the option described below:
>
> ---
> The ability to POST a .jmx file to a running jMeter server over an
> HTTP connection using a REST (or SOAP) interface and return the results,
> either directly (in the same connection) or via a call-back URL. This
> would be the equivalent of using -t and -l options on the command-line
> with the benefit that the server runs continuously and the client-side
> calls for executing a script become very cheap (i.e. no Java startup
> time). The API should be documented and specs made available to the
> community.
> ---
>
> We would like to know if this is in fact feasible (or even sensible)
> project. And if so, we are hoping to be able to sponsor a large part of
> the development costs for any jMeter developer who likes to develop
> this. The goal of this project is to have this included in vanilla
> jMeter in a way such that the jMeter community is able to support and
> maintain the code (with us) after the initial development. Therefore,
> naturally, the implementation would be licensed under the same license
> as jMeter.
>
> Please let us know your opinion.
>
> Kind regards,
> --
> Pieter Ennes
> WatchMouse
>
> e-mail: pieter @ watchmouse.com
> europe: +31 (0) 8787 58 323
> us    : +1 415 373 5263
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-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: jMeter development project inquiry

[Pieter Ennes <pi...@watchmouse.com>]

Hi sebb,

Thanks.

sebb wrote:
> It's already possible to run multiple JMX files in GUI mode (though
> not automatically), and the server in client-server mode can be left
> running between test runs, so that Java startup-time is restricted to
> the client.
> 
> Batch mode only processes the single jmx file provided on the command-line.
> 
> I'm sure it would be to extend JMeter as proposed.
> However the proposal requires an extra process to send the JMX data
> and to receive the results, both of which add extra overhead.

I'm afraid that all the suggested options will not work in our case
(being: running a diversity of scripts every ~5 minutes each).

>From what I've tested the overhead just becomes too large in batch mode,
and in our case we do not know more than a few seconds in advance which
files to play. This is what we're hoping to achieve by implementing a
REST interface: instant action.

As a bonus, hopefully, this will make the platform more accessible to
people using other (non-Java/RMI) languages and may stimulate them to
use the jMeter API, broadening the jMeter use cases and user base. I
would very much like to know if there are other people interested in
interfacing with jMeter using a public API (whatever kind), and also in
what way this API should then be implemented.

Maybe our proposed method (posting and returning XML) is not the way
to go here and it would be better to implement lower-level calls, to
obtain flexibility and extend possibilities for programmers. Please
share any thoughts on this, as an API will be rather useless if it only
covers one or two special cases and is not supported by the interest of
several people.

> Perhaps it would be simpler to implement an option to process all JMX
> files in a directory, or listed in a file.

This sounds good. What about combining this with jmeter in server mode:
Send it a (HUP?) signal to have it re-read the contents of this
directory and process the files.

Best regards,
-- 
Pieter Ennes
WatchMouse

e-mail: pieter @ watchmouse.com
europe: +31 (0) 8787 58 323
us    : +1 415 373 5263

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

Re: jMeter development project inquiry

[Pieter Ennes <pi...@watchmouse.com>]

Hi sebb,

Thanks.

sebb wrote:
> It's already possible to run multiple JMX files in GUI mode (though
> not automatically), and the server in client-server mode can be left
> running between test runs, so that Java startup-time is restricted to
> the client.
> 
> Batch mode only processes the single jmx file provided on the command-line.
> 
> I'm sure it would be to extend JMeter as proposed.
> However the proposal requires an extra process to send the JMX data
> and to receive the results, both of which add extra overhead.

I'm afraid that all the suggested options will not work in our case
(being: running a diversity of scripts every ~5 minutes each).

>From what I've tested the overhead just becomes too large in batch mode,
and in our case we do not know more than a few seconds in advance which
files to play. This is what we're hoping to achieve by implementing a
REST interface: instant action.

As a bonus, hopefully, this will make the platform more accessible to
people using other (non-Java/RMI) languages and may stimulate them to
use the jMeter API, broadening the jMeter use cases and user base. I
would very much like to know if there are other people interested in
interfacing with jMeter using a public API (whatever kind), and also in
what way this API should then be implemented.

Maybe our proposed method (posting and returning XML) is not the way
to go here and it would be better to implement lower-level calls, to
obtain flexibility and extend possibilities for programmers. Please
share any thoughts on this, as an API will be rather useless if it only
covers one or two special cases and is not supported by the interest of
several people.

> Perhaps it would be simpler to implement an option to process all JMX
> files in a directory, or listed in a file.

This sounds good. What about combining this with jmeter in server mode:
Send it a (HUP?) signal to have it re-read the contents of this
directory and process the files.

Best regards,
-- 
Pieter Ennes
WatchMouse

e-mail: pieter @ watchmouse.com
europe: +31 (0) 8787 58 323
us    : +1 415 373 5263

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