Thanks for the advice. I was wondering if I could somehow have something that would start some sort of logging on an external client before beginning the test, then stopping it once the test completes. If I could write a shell script or something that would poll every 5 seconds or something to select the values I want and log them itself.
The only real requirement is that it be turnkey in the sense I put stuff in the right spots and click Go. If I have to create some graphs from a csv or such that isn't too big of a deal as long as I can relatively easily compile the results. Maybe I will look into firing off the JMeter test via a command line and then before running it turn on some sort of monitoring system like cacti and then stop it once i hit the end of the test or a defined time frame. Thanks again! josh On Wed, Dec 15, 2010 at 1:40 PM, Anthony Johnson <[email protected]> wrote: > Hey Josh, > I have to agree with deepak. My team had the same requirement. > The solution we came up with was to create our own Sampler that has > the ability to hit an SNMP interface and graph that data via jrobin. > This was a major commitment on our part and has proven quite useful > for our needs(I can't share with the community yet). Knowing how much > work it was, I would recommend using an external monitoring station > instead to capture the data. Something like this: > > 1. Normalize your environment and use something like Cacti to create > beautiful graphs for all that you want to see. I see topics on Cacti > around JMX, so I'm sure you can find an easy way to get the data you > need into it. > 2. At the end of the test you can use a BSH Sampler to HTTP GET all > the graph data for the timeframe of the test. The way I would > implement this would be a common beanshell script that can connect to > a URL and save the graph image/data locally. Then just pass arguments > into the script from the BSH Sampler. > 3. Since you would need to only trigger the beanshell when your test > is done, the test would have to be designed in way that the end can be > known. > > Beanshell has a decent manual and several examples exists for Java to > pull the data from the monitoring station to your JMeter station ( > > http://download.oracle.com/javase/tutorial/networking/urls/readingWriting.html > ). > > Hope this helps, > > Anthony > > > On Wed, Dec 15, 2010 at 2:31 PM, Josh Abts <[email protected]> > wrote: > > 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 <[email protected]> > 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 <[email protected]> > >> 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 <[email protected]> wrote: > >> > > >> > > On 10 December 2010 20:04, Josh Abts <[email protected]> > 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: [email protected] > >> > > For additional commands, e-mail: > [email protected] > >> > > > >> > > > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
