You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jmeter-dev@jakarta.apache.org by Brett Cave <br...@gmail.com> on 2010/02/24 20:24:07 UTC

Re: Effectively monitoring target resources with jmeter?

On Wed, Feb 24, 2010 at 9:07 PM, sebb <se...@gmail.com> wrote:

> On 24/02/2010, Brett Cave <br...@gmail.com> wrote:
> > MysqlCollector plugin added to JMeter wiki:
> >
> >  http://wiki.apache.org/jakarta-jmeter/MysqlCollectorPlugin (check
> >  attachments for the patch).
>
> Have a look at the Summariser class - this uses the TestListener
> interface for setUp/tearDown of items that are needed for each test.
> This could be used for setting up and closing the connection etc.
>

Ok perfect, will do that. Used the ResultSaver class for reference to get
familiar with plugin development,

>
> Most of the code is generic SQL - however the database creation is not.
> Since that only has to be done once, it could be done outside JMeter.
>
> By database creation, do you mean table creation or setting up of the
connection? The table will only be created if it doesn't exist and the
create table option is selected from the GUI.



> Provided that you implement the correct interface(s), JMeter will find
> the add-ons.
> That's how it finds all the existing samplers and listeners etc.
> Just put them in a jar and put the jar in lib/ext.
>
> To avoid problems with missing properties, override getStaticLabel()
> rather than getLabelResource().
>

Great, will do. Not sure why it was looking for the default org.apache
package. The code was originally in org.apache, but then moved to a new one,
re-archived the jar in lib/ext (with JMeter closed) and then started JMeter
again. possibly cached classes somewhere?



> Or use the TestBean method for implementing the GUI; each class has
> its own resource file.
>
> This is starting to be more appropriate for the JMeter developer
> mailing list ...
>

Done

Re: Effectively monitoring target resources with jmeter?

Posted by sebb <se...@gmail.com>.
On 24/02/2010, Brett Cave <br...@gmail.com> wrote:
> On Wed, Feb 24, 2010 at 9:07 PM, sebb <se...@gmail.com> wrote:
>
>  > On 24/02/2010, Brett Cave <br...@gmail.com> wrote:
>  > > MysqlCollector plugin added to JMeter wiki:
>  > >
>  > >  http://wiki.apache.org/jakarta-jmeter/MysqlCollectorPlugin (check
>  > >  attachments for the patch).
>  >
>
> > Have a look at the Summariser class - this uses the TestListener
>  > interface for setUp/tearDown of items that are needed for each test.
>  > This could be used for setting up and closing the connection etc.
>  >
>
>
> Ok perfect, will do that. Used the ResultSaver class for reference to get
>  familiar with plugin development,
>
>
>  >
>  > Most of the code is generic SQL - however the database creation is not.
>  > Since that only has to be done once, it could be done outside JMeter.
>  >
>
> > By database creation, do you mean table creation or setting up of the
>  connection? The table will only be created if it doesn't exist and the
>  create table option is selected from the GUI.
>
>

Table creation.

Users may wish to use Derby or Oracle or some other database.

So long as the appropriate column names and types are created, the
rest of the code should then work with any JDBC database.

>
>  > Provided that you implement the correct interface(s), JMeter will find
>  > the add-ons.
>  > That's how it finds all the existing samplers and listeners etc.
>  > Just put them in a jar and put the jar in lib/ext.
>  >
>  > To avoid problems with missing properties, override getStaticLabel()
>  > rather than getLabelResource().
>  >
>
>
> Great, will do. Not sure why it was looking for the default org.apache
>  package. The code was originally in org.apache, but then moved to a new one,
>  re-archived the jar in lib/ext (with JMeter closed) and then started JMeter
>  again. possibly cached classes somewhere?
>

JMeter does not cache classes between runs.

>
>
>  > Or use the TestBean method for implementing the GUI; each class has
>  > its own resource file.
>  >
>  > This is starting to be more appropriate for the JMeter developer
>  > mailing list ...
>  >
>
>
> Done
>

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