jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: timing issue when running remote tests against two slaves
Date Wed, 09 Nov 2011 17:32:35 GMT
On 9 November 2011 16:26, Bruce Ide <flyingrhenquest@gmail.com> wrote:
> Seems like running NTP would be an easy work-around.
>
> From a technical perspective, the clients could just set an epoch at the
> start of the test and record samples from the start of the epoch. Then you
> could normalize to the server's time or whatever without too much
> difficulty. It would probably just be a matter of a couple of
> changes to the SampleResult generation code.

The results are generated on the individual hosts.
They are then combined on the client, which is where any clock skew
will cause problems.

If the client/server exchanged currentTimeMillis at the start of a
test, then either the client or the server could "normalise" the
clocks.
Probably better for the client to do it as the server would not know
how "old" the client message was.
Whereas the client can measure any delay in initial the server
response and take appropriate action.

Proper normalisation implies that JMeter somehow knows which clock is
correct; I don't think that's possible.
All that JMeter could do is pick one of the values - or an average -
and use that.

> I'm all entrenched in my current project and won't have free time until
> sometime in 2012. All the source is out there, though, so if you know (or
> are) a java programmer who can submit a patch, you could probably get a
> feature in sooner rather than later.

Indeed, patches via Bugzilla welcome.
[Please don't send patches to the list; please use unified diff format]

> --
> Bruce Ide
> FlyingRhenquest@gmail.com
>

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


Mime
View raw message