jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Abts <josh.a...@vistracks.com>
Subject Re: Monitoring Other Values During Test?
Date Wed, 15 Dec 2010 19:31:45 GMT
I didn't think about the simultaneous calls to JMX.

Basically I want to be able to see values over time of various indicators
that are accessible through JMX.  I could graph it separately and monitor
through another script, but ideally, we want this to be an all in one
solution.  Run the test, see the results.  Not have to merge 3 different
graphs and csv files, etc.

I am using the jmeter-plugins from the google projects page to graph
cpu/memory/disk io over time, and I would love something almost exactly the
same but graphing these certain JMX indicators.

So far I have it working by updating the sample variables and using a
beanshell postprocessor in order to update the vars with the JMX values.
Then we can at least access those via CSV and graph them myself.

Thanks for the input,
Josh

On Wed, Dec 15, 2010 at 1:23 PM, Deepak Shetty <shettyd@gmail.com> wrote:

> Hi
> My 2 cents.
>
> i wouldnt do it this way. Most app servers have low impact monitoring tools
> that run within the app server that allow them to write JMX data to files
> in
> various combinations (especially alerting kind of JMX - notify if free
> connections fall to < 3 or something) so I am not really in favor of a one
> client does all solution - its easier to combine results.
>
> Also if you code this yourself from an external client then you must
> account
> for the additional load that you are putting on the server(as opposed to
> the
> app server which will usually give you figures like expect 2% reduction per
> 10 attributes monitored or something) . The sample variables are recorded
> per thread - why would you want to do that?. If you are running say a 100
> threads you dont really want to make a 100 concurrent JMX calls so you'd
> have to code it to say only 1 thread actually makes the call. Usually you
> want this to be interval based (monitor every x minutes or so) which doesnt
> fit into sample_variables easily.
>
> regards
> deepak
>
> On Wed, Dec 15, 2010 at 6:55 AM, Josh Abts <josh.abts@vistracks.com>
> wrote:
>
> > I like the idea of the sample variables.  The question now is is there
> any
> > sample code/examples of how to connect say a JMX (java management) value
> to
> > variable.
> >
> > My best guess would be a BeanShell sampler with some sort of custom Java
> > code, but is there a cleaner/easier way?
> >
> > On Mon, Dec 13, 2010 at 5:27 AM, sebb <sebbaz@gmail.com> wrote:
> >
> > > On 10 December 2010 20:04, Josh Abts <josh.abts@vistracks.com> wrote:
> > > > Is it possible to monitor other values somehow during a JMeter test?
> > >
> > > You can record variables using:
> > >
> > >
> >
> http://jakarta.apache.org/jmeter/usermanual/listeners.html#sample_variables
> > >
> > > So if you can get the value in a variable, you can associate if with
> > > each sample.
> > >
> > > > For example I may want to graph load average over time in conjunction
> > > with
> > > > the test that is being run.  Is it possible to do this all in a
> single
> > > > interface (JMeter) through some listener or is it only possible if
> done
> > > > through a separate utility?  Alternatively if I can access the value
> I
> > > want
> > > > through JMX, is there a way of accessing that value and graphing it
> or
> > > > recording it along with the thread requests?
> > > >
> > > > Basically, it would be nice if it is possible to have this be
> turn-key
> > in
> > > > the sense that we can do one test and have one place to record and
> > > monitor
> > > > all the data and then break it apart ourselves if necessary.
> > > >
> > > > Thanks!
> > > >
> > > > --
> > > > Joshua Abts
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> > >
> > >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message