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 < gokul...@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. >
