You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Gokulakannan Somasundaram <go...@gmail.com> on 2009/09/16 14:05:45 UTC

Integrating Monitoring stuff

Hi,
   We are exploring options to integrate DTrace profiling results in JMeter.
It would be more like while we are running the test, we can see how much
time some important methods are taking to execute. I am planning to add a
listener, into the JMeter GUI, which would take up the name pattern with
which we can identify the particular process from the output of  jps. Then
use th jinfo command to enable the extended DTace Probes and use the pid of
the process to enable probe for the same.
    The disadvantages are it would work only Java 1.6 and Solaris. In
future, may be Linux might also start supporting DTrace.
    Can this work accepted into JMeter? Has this been already discussed in
this forum? Can someone help me on this?

Thanks,
Gokul.

Re: Integrating Monitoring stuff

Posted by Gokulakannan Somasundaram <go...@gmail.com>.
On Wed, Sep 16, 2009 at 6:58 PM, Peter Lin <wo...@gmail.com> wrote:

> sounds like a useful feature.
>
> As far as  know, DTrace has been ported to linux and OSX, so it should
> work on solaris, linux and osx.
>
> it won't work on windows obviously. the sampler should be fairly
> straight forward. Are you planning on using JNI to invoke DTrace?
>
>
Currently my plan is to use the Runtime.getRuntime().exec() functionality,
as DTrace programming is done in D Language. Although it is similar to C, i
don't know, whether it will work with JNI. But as you say, running through
JNI has its own advantages for communicating the results and control back
and forth. Let me explore that once we are done with the current one.

Thanks,
Gokul.

Re: Integrating Monitoring stuff

Posted by Peter Lin <wo...@gmail.com>.
sounds like a useful feature.

As far as  know, DTrace has been ported to linux and OSX, so it should
work on solaris, linux and osx.

it won't work on windows obviously. the sampler should be fairly
straight forward. Are you planning on using JNI to invoke DTrace?

peter


On Wed, Sep 16, 2009 at 8:05 AM, Gokulakannan Somasundaram
<go...@gmail.com> wrote:
> Hi,
>   We are exploring options to integrate DTrace profiling results in JMeter.
> It would be more like while we are running the test, we can see how much
> time some important methods are taking to execute. I am planning to add a
> listener, into the JMeter GUI, which would take up the name pattern with
> which we can identify the particular process from the output of  jps. Then
> use th jinfo command to enable the extended DTace Probes and use the pid of
> the process to enable probe for the same.
>    The disadvantages are it would work only Java 1.6 and Solaris. In
> future, may be Linux might also start supporting DTrace.
>    Can this work accepted into JMeter? Has this been already discussed in
> this forum? Can someone help me on this?
>
> Thanks,
> Gokul.
>

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


Re: Integrating Monitoring stuff

Posted by Gokulakannan Somasundaram <go...@gmail.com>.
Hi Sebb,
      I have filed  a enhancement issue in Bugzilla and attached the files
and the request no. is *Bug
48145*<https://issues.apache.org/bugzilla/show_bug.cgi?id=48145>
.
Please let me know on how i can proceed further on integration.

Thanks,
Gokul.

Re: Integrating Monitoring stuff

Posted by sebb <se...@gmail.com>.
On 05/11/2009, Gokulakannan Somasundaram <go...@gmail.com> wrote:
> Attaching the files, mentioned in the previous mail.
>

The files did not come through, and anyway it's difficult to keep
track of mailing list patches.

Please create a Bugzilla issue, and attach the files to that.

>
> a) Copy the attached files into one directory
>
> b) Make sure the current directory and the jar file
> /usr/share/lib/java/dtrace.jar are in the class path
>
> c) The methods to be monitored are to be provided with the file input.txt in
> the form package,class,method
>
> d) Make sure to login with the same userid with which the process was
> started
>
> e) compile the MethodProfiler.java using javac MethodProfiler.java
>
> f) run "java MethodProfiler <pid of the jvm>"
>
>
>
> The output will contain the DTrace output. But the average_time, max time
> and distribution can be identified out of the output with little bit of
> difficulty.
>
>  Thanks,
> Gokul.
>
>
> ---------------------------------------------------------------------
>  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-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Re: Integrating Monitoring stuff

Posted by Gokulakannan Somasundaram <go...@gmail.com>.
Attaching the files, mentioned in the previous mail.

a) Copy the attached files into one directory

b) Make sure the current directory and the jar file
/usr/share/lib/java/dtrace.jar are in the class path

c) The methods to be monitored are to be provided with the file input.txt in
the form package,class,method

d) Make sure to login with the same userid with which the process was
started

e) compile the MethodProfiler.java using javac MethodProfiler.java

f) run "java MethodProfiler <pid of the jvm>"



The output will contain the DTrace output. But the average_time, max time
and distribution can be identified out of the output with little bit of
difficulty.

 Thanks,
Gokul.

Re: Integrating Monitoring stuff

Posted by Gokulakannan Somasundaram <go...@gmail.com>.
The update is that i was able to create a DTrace script and monitor method
level timings. But then i had trouble using the Runtime.Exec of java to
execute and get the output periodically.

I found that there is a library called jDTrace and it comes with Solaris 11
build 30 or later.  This provides an interface to DTrace from Java. So i
used it in my code.

DTrace makes use of a scripting language called which is very limited in its
expressiveness. It doesn't have if conditions, for loops or string
manipulation stuffs. So everytime the requirements are changed, i am
creating a new DTrace script, using gawk( GNU version of awk ). So the
prerequisistes for using this would be
a) Solaris 11 build 30 or later
b) gawk

Now i have a java program which takes the pid and the methods to be
monitored(along with class and package) and gives the following stats

a) average time taken every 5 seconds
b) Min and Max time taken every 5 seconds
c) Frequency distribution of method call timings every 5 seconds.

There are some probes in DTrace like the profile probes, which requires
DTrace Kernel privilege to get fired. But the script which gets generated
here doesn't require any extra privileges. It onyl requires you to start the
monitoring stuff  with the same user id, with which the process to monitor
was started.

Now the final part of the puzzle is to integrate it with JMeter. Will this
be useful to the community and can i get some guidance on the integrating
part?

Thanks,
Gokul.

Re: Integrating Monitoring stuff

Posted by Gokulakannan Somasundaram <go...@gmail.com>.
On Mon, Oct 5, 2009 at 7:04 PM, Tony Lotts <tl...@gmail.com> wrote:

> Sending the data back to JMeter, and running an RMI server on the SUT will
> add overhead to the SUT in addition to DTrace.


I think logging it in SUT / Sending it to a different system for logging
doesn't make much difference. When we run a profiler on the SUT, there will
be a overhead anyways, even in  existing profiling scenarios.



> Why not just coordinate the
> times with the times from Jmeter after the test?
>

This is definitely possible even with a simple Java Sampler. But then we
come to know of the profiling results only after the test is over. In the
one i explained, the profiling results can be viewed online.

Thanks,
Gokul.

Re: Integrating Monitoring stuff

Posted by Tony Lotts <tl...@gmail.com>.
Sending the data back to JMeter, and running an RMI server on the SUT will
add overhead to the SUT in addition to DTrace.  Why not just coordinate the
times with the times from Jmeter after the test?

On Mon, Oct 5, 2009 at 9:09 AM, Gokulakannan Somasundaram <
gokul007@gmail.com> wrote:

> I started working on this and i was looking into the source code of JMeter.
> Here are my initial observations.
>
> a) My aim is to display the profiling stuff in the form of current Summary
> Report. This is because, this is how even other profiling tools display
> info.
>
> b) This requires a RMI Server at the SUT(Server Under Test)
>
> c) It can be made to generate a SamplerResult and send it back to the
> JMeter
> GUI. This is similar to Remote Testing, but the problem is that i find the
> configuration for one machine in the RemoteTesting is the same as another.
> For example, it is not possible for me to mention different threading
> configurations for different machines involved in Remote Testing
>
> So i feel a clean design would be to implement profiling is to
> a) Implement variable load facility as mentioned above in  (c)
> b) Subclass SamplerResult to ProfilerResult, so that it is skipped by the
> rest of the visualizers. Actually, if we make it look like a normal sample,
> then creating GUI Elements specific to profiling results will not be
> possible.
>
> Any thoughts/comments?
>
> Gokul.
>

Re: Integrating Monitoring stuff

Posted by Gokulakannan Somasundaram <go...@gmail.com>.
I started working on this and i was looking into the source code of JMeter.
Here are my initial observations.

a) My aim is to display the profiling stuff in the form of current Summary
Report. This is because, this is how even other profiling tools display
info.

b) This requires a RMI Server at the SUT(Server Under Test)

c) It can be made to generate a SamplerResult and send it back to the JMeter
GUI. This is similar to Remote Testing, but the problem is that i find the
configuration for one machine in the RemoteTesting is the same as another.
For example, it is not possible for me to mention different threading
configurations for different machines involved in Remote Testing

So i feel a clean design would be to implement profiling is to
a) Implement variable load facility as mentioned above in  (c)
b) Subclass SamplerResult to ProfilerResult, so that it is skipped by the
rest of the visualizers. Actually, if we make it look like a normal sample,
then creating GUI Elements specific to profiling results will not be
possible.

Any thoughts/comments?

Gokul.

Re: Integrating Monitoring stuff

Posted by Thomas Johnson <nt...@gmail.com>.
It sounds like a pretty cool project. Good luck with getting it all running
:)
It looks like dtrace already has bindings for both C (libdtrace) and Java (
http://www.opensolaris.org/os/project/dtrace-chime/java_dtrace_api/) so you
might be able to reuse existing technology.

It sounds like the two aren't exactly well-maintained though, and it's not
obvious whether the Java dtrace library will handle the Mac version, but you
might have some luck. Worst-case, you might need to modify/maintain the
libraries yourself, but that sounds like a pretty fun task anyway.

Other references:
http://opensolaris.org/jive/thread.jspa?threadID=40519
http://blogs.sun.com/tomee/date/20050614

On Thu, Sep 24, 2009 at 3:26 AM, sebb <se...@gmail.com> wrote:

> On 17/09/2009, Gokulakannan Somasundaram <go...@gmail.com> wrote:
> > >
> >  >
> >  > However, if the Listener can be written to accept perfomance data from
> >  > different sources, and a suitable data format is published, it might
> >  > be useful to include it as a standard part of JMeter.
> >  >
> >  >
> >
> > Can i get some help here?  I can definitely make the Listener accept the
> >  performance data in a particular format(say some XML Schema). But still
> it
> >  would have the restriction of JVM 1.6 (since jinfo works only in that
> >  version) and will work only with Solaris.
>
> There are two issues here:
> - whether JMeter will build on Java 1.5 non-Solaris
> - whether JMeter will run on Java 1.5 non-Solaris if the monitoring
> code is not used.
>
> If you use exec(), then AFAICT JMeter will be unaffected; however the
> new monitoring code won't be usable except on Solaris/Java 1.6.
>
> If you decide to use JNI, then JMeter must still be usable without the
> JNI module.
>
> >  Thanks,
> >  Gokul.
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

Re: Integrating Monitoring stuff

Posted by sebb <se...@gmail.com>.
On 17/09/2009, Gokulakannan Somasundaram <go...@gmail.com> wrote:
> >
>  >
>  > However, if the Listener can be written to accept perfomance data from
>  > different sources, and a suitable data format is published, it might
>  > be useful to include it as a standard part of JMeter.
>  >
>  >
>
> Can i get some help here?  I can definitely make the Listener accept the
>  performance data in a particular format(say some XML Schema). But still it
>  would have the restriction of JVM 1.6 (since jinfo works only in that
>  version) and will work only with Solaris.

There are two issues here:
- whether JMeter will build on Java 1.5 non-Solaris
- whether JMeter will run on Java 1.5 non-Solaris if the monitoring
code is not used.

If you use exec(), then AFAICT JMeter will be unaffected; however the
new monitoring code won't be usable except on Solaris/Java 1.6.

If you decide to use JNI, then JMeter must still be usable without the
JNI module.

>  Thanks,
>  Gokul.
>

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


Re: Integrating Monitoring stuff

Posted by Gokulakannan Somasundaram <go...@gmail.com>.
>
>
> However, if the Listener can be written to accept perfomance data from
> different sources, and a suitable data format is published, it might
> be useful to include it as a standard part of JMeter.
>
>
Can i get some help here?  I can definitely make the Listener accept the
performance data in a particular format(say some XML Schema). But still it
would have the restriction of JVM 1.6 (since jinfo works only in that
version) and will work only with Solaris.

Thanks,
Gokul.

Re: Integrating Monitoring stuff

Posted by sebb <se...@gmail.com>.
On 16/09/2009, Gokulakannan Somasundaram <go...@gmail.com> wrote:
> Hi,
>    We are exploring options to integrate DTrace profiling results in JMeter.
>  It would be more like while we are running the test, we can see how much
>  time some important methods are taking to execute. I am planning to add a
>  listener, into the JMeter GUI, which would take up the name pattern with
>  which we can identify the particular process from the output of  jps. Then
>  use th jinfo command to enable the extended DTace Probes and use the pid of
>  the process to enable probe for the same.
>     The disadvantages are it would work only Java 1.6 and Solaris. In
>  future, may be Linux might also start supporting DTrace.
>     Can this work accepted into JMeter?

JMeter is platform-agnostic; it should work on all systems that
support the minimum required JVM. So it's not really in scope to add
such a specific sampler.

However, if the Listener can be written to accept perfomance data from
different sources, and a suitable data format is published, it might
be useful to include it as a standard part of JMeter.

Otherwise, you can always publish the code yourself, and provide a
link from the JMeter Wiki.

> Has this been already discussed in this forum?

Not that I recall, but you can search the JMeter mailing lists.

> Can someone help me on this?
>
>  Thanks,
>  Gokul.
>

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