You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by "pay@mapisimo.com" <pa...@mapisimo.com> on 2011/11/09 15:44:05 UTC
timing issue when running remote tests against two slaves
I am having problems when running tests against two slaves.
When the tests run locally or against one slave, everything is ok and I get
190 requests in about 5 seconds.
When the tests are run against *two* slaves, I get 380 requests in *
4449685.4 seconds. This looks like a bug.
*
*
Please see below the output of my runs
*
*
*
*
First, remotely against local host, is ok
*
*
Second, remotely against other computer, is ok
*
*
Third, remotely against both local and other computer, actually takes a few
seconds but
**
4449685.4 are reported.
*
*
Last, running locally, seems to be ok too.
*
*
*
C:\copia\jmeter\bin>jmeter -Gthreads=1 -t thecopia.jmx
-Jremote_hosts=127.0.0.1 -n -r
Created the tree successfully using thecopia.jmx
Configuring remote engine for 127.0.0.1
Using remote object: UnicastRef [liveRef:
[endpoint:[172.20.30.136:63970](remote),objID:[-3a6c2691:13388a7257e:-7fff,
-4439546713033534964]]]
Starting remote engines
Starting the test @ Wed Nov 09 16:36:19 IST 2011 (1320849379555)
Remote engines have been started
Waiting for possible shutdown message on port 4445
Generate Summary Results = 190 in 4.7s = 40.7/s Avg: 45 Min: 1
Max: 1815 Err: 9 (4.74%)
Tidying up remote @ Wed Nov 09 16:36:24 IST 2011 (1320849384380)
... end of run
C:\copia\jmeter\bin>jmeter -Gthreads=1 -t thecopia.jmx
-Jremote_hosts=172.20.90.41 -n -r
Created the tree successfully using thecopia.jmx
Configuring remote engine for 172.20.90.41
Using remote object: UnicastRef [liveRef:
[endpoint:[172.20.90.41:62006](remote),objID:[61bb08df:1327eb66baa:-7fff,
5888908496307605252]]]
Starting remote engines
Starting the test @ Wed Nov 09 16:36:56 IST 2011 (1320849416211)
Remote engines have been started
Waiting for possible shutdown message on port 4445
Generate Summary Results = 190 in 7.1s = 26.8/s Avg: 58 Min: 1
Max: 2650 Err: 9 (4.74%)
Tidying up remote @ Wed Nov 09 16:37:03 IST 2011 (1320849423492)
... end of run
C:\copia\jmeter\bin>jmeter -Gthreads=1 -t thecopia.jmx
-Jremote_hosts=172.20.90.41,127.0.0.1 -n -r
Created the tree successfully using thecopia.jmx
Configuring remote engine for 172.20.90.41
Using remote object: UnicastRef [liveRef:
[endpoint:[172.20.90.41:62006](remote),objID:[61bb08df:1327eb66baa:-7fff,
5888908496307605252]]]
Configuring remote engine for 127.0.0.1
Using remote object: UnicastRef [liveRef:
[endpoint:[172.20.30.136:63970](remote),objID:[-3a6c2691:13388a7257e:-7fff,
-4439546713033534964]]]
Starting remote engines
Starting the test @ Wed Nov 09 16:37:17 IST 2011 (1320849437137)
Remote engines have been started
Waiting for possible shutdown message on port 4445
Generate Summary Results = 380 in 4449685.4s = 0.0/s Avg: 51 Min:
1 Max: 2601 Err: 18 (4.74%)
Tidying up remote @ Wed Nov 09 16:37:23 IST 2011 (1320849443845)
... end of run
C:\copia\jmeter\bin>jmeter -Gthreads=1 -t thecopia.jmx
-Jremote_hosts=172.20.90.41,127.0.0.1 -n
Created the tree successfully using thecopia.jmx
Starting the test @ Wed Nov 09 16:37:35 IST 2011 (1320849455537)
Waiting for possible shutdown message on port 4445
Generate Summary Results = 190 in 5.0s = 37.8/s Avg: 52 Min: 1
Max: 1695 Err: 9 (4.74%)
Tidying up ... @ Wed Nov 09 16:37:40 IST 2011 (1320849460684)
... end of run
Re: timing issue when running remote tests against two slaves
Posted by sebb <se...@gmail.com>.
On 9 November 2011 19:06, Bruce Ide <fl...@gmail.com> wrote:
> Sure! Just establish a start epoch at the start of the test. The epoch will
> have the time. Then just have all samples record as deltas from the epoch.
> So your first sample would start at zero. Then you can adjust them to any
> time you want to at a later date. The server could adjust all the samples
> to be from when it thinks the test started.
Please don't top post, makes it tricky to follow the thread.
I don't think it's a simple as that.
If samples are epoch-based, then where do the Listeners get the epoch
details from in order to work out the actual time?
Also, this will mess up any code that relies on the sample start and
end-times; e.g. 3rd party analysis.
> On Nov 9, 2011 10:33 AM, "sebb" <se...@gmail.com> wrote:
>
>> On 9 November 2011 16:26, Bruce Ide <fl...@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
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org
Re: timing issue when running remote tests against two slaves
Posted by Bruce Ide <fl...@gmail.com>.
Sure! Just establish a start epoch at the start of the test. The epoch will
have the time. Then just have all samples record as deltas from the epoch.
So your first sample would start at zero. Then you can adjust them to any
time you want to at a later date. The server could adjust all the samples
to be from when it thinks the test started.
On Nov 9, 2011 10:33 AM, "sebb" <se...@gmail.com> wrote:
> On 9 November 2011 16:26, Bruce Ide <fl...@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
>
>
Re: timing issue when running remote tests against two slaves
Posted by sebb <se...@gmail.com>.
On 9 November 2011 16:26, Bruce Ide <fl...@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
Re: timing issue when running remote tests against two slaves
Posted by Bruce Ide <fl...@gmail.com>.
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.
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.
--
Bruce Ide
FlyingRhenquest@gmail.com
Re: timing issue when running remote tests against two slaves
Posted by "pay@mapisimo.com" <pa...@mapisimo.com>.
*Indeed. I synced the clocks and now it is ok.*
*Anyway, I would expect that the chronometer works by measuring time deltas
not across computers, so it does not depend on the accuracy of
the synchronization. Perhaps this is still a bug (or enhancement request)?*
*
*
*Anyway, thanks to your prompt answer now this is much less urgent.*
Re: timing issue when running remote tests against two slaves
Posted by sebb <se...@gmail.com>.
On 9 November 2011 14:44, pay@mapisimo.com <pa...@mapisimo.com> wrote:
> I am having problems when running tests against two slaves.
> When the tests run locally or against one slave, everything is ok and I get
> 190 requests in about 5 seconds.
> When the tests are run against *two* slaves, I get 380 requests in *
> 4449685.4 seconds. This looks like a bug.
If it was a bug, I would expect it to have been noticed before now ...
most likely your slave clocks are not in synch.
> *
> *
> Please see below the output of my runs
> *
> *
>
> *
> *
> First, remotely against local host, is ok
> *
> *
> Second, remotely against other computer, is ok
> *
> *
> Third, remotely against both local and other computer, actually takes a few
> seconds but
> **
> 4449685.4 are reported.
> *
> *
> Last, running locally, seems to be ok too.
> *
> *
>
> *
> C:\copia\jmeter\bin>jmeter -Gthreads=1 -t thecopia.jmx
> -Jremote_hosts=127.0.0.1 -n -r
> Created the tree successfully using thecopia.jmx
> Configuring remote engine for 127.0.0.1
> Using remote object: UnicastRef [liveRef:
> [endpoint:[172.20.30.136:63970](remote),objID:[-3a6c2691:13388a7257e:-7fff,
> -4439546713033534964]]]
> Starting remote engines
> Starting the test @ Wed Nov 09 16:36:19 IST 2011 (1320849379555)
> Remote engines have been started
> Waiting for possible shutdown message on port 4445
> Generate Summary Results = 190 in 4.7s = 40.7/s Avg: 45 Min: 1
> Max: 1815 Err: 9 (4.74%)
> Tidying up remote @ Wed Nov 09 16:36:24 IST 2011 (1320849384380)
> ... end of run
>
> C:\copia\jmeter\bin>jmeter -Gthreads=1 -t thecopia.jmx
> -Jremote_hosts=172.20.90.41 -n -r
> Created the tree successfully using thecopia.jmx
> Configuring remote engine for 172.20.90.41
> Using remote object: UnicastRef [liveRef:
> [endpoint:[172.20.90.41:62006](remote),objID:[61bb08df:1327eb66baa:-7fff,
> 5888908496307605252]]]
> Starting remote engines
> Starting the test @ Wed Nov 09 16:36:56 IST 2011 (1320849416211)
> Remote engines have been started
> Waiting for possible shutdown message on port 4445
> Generate Summary Results = 190 in 7.1s = 26.8/s Avg: 58 Min: 1
> Max: 2650 Err: 9 (4.74%)
> Tidying up remote @ Wed Nov 09 16:37:03 IST 2011 (1320849423492)
> ... end of run
>
> C:\copia\jmeter\bin>jmeter -Gthreads=1 -t thecopia.jmx
> -Jremote_hosts=172.20.90.41,127.0.0.1 -n -r
> Created the tree successfully using thecopia.jmx
> Configuring remote engine for 172.20.90.41
> Using remote object: UnicastRef [liveRef:
> [endpoint:[172.20.90.41:62006](remote),objID:[61bb08df:1327eb66baa:-7fff,
> 5888908496307605252]]]
> Configuring remote engine for 127.0.0.1
> Using remote object: UnicastRef [liveRef:
> [endpoint:[172.20.30.136:63970](remote),objID:[-3a6c2691:13388a7257e:-7fff,
> -4439546713033534964]]]
> Starting remote engines
> Starting the test @ Wed Nov 09 16:37:17 IST 2011 (1320849437137)
> Remote engines have been started
> Waiting for possible shutdown message on port 4445
> Generate Summary Results = 380 in 4449685.4s = 0.0/s Avg: 51 Min:
> 1 Max: 2601 Err: 18 (4.74%)
> Tidying up remote @ Wed Nov 09 16:37:23 IST 2011 (1320849443845)
> ... end of run
>
> C:\copia\jmeter\bin>jmeter -Gthreads=1 -t thecopia.jmx
> -Jremote_hosts=172.20.90.41,127.0.0.1 -n
> Created the tree successfully using thecopia.jmx
> Starting the test @ Wed Nov 09 16:37:35 IST 2011 (1320849455537)
> Waiting for possible shutdown message on port 4445
> Generate Summary Results = 190 in 5.0s = 37.8/s Avg: 52 Min: 1
> Max: 1695 Err: 9 (4.74%)
> Tidying up ... @ Wed Nov 09 16:37:40 IST 2011 (1320849460684)
> ... end of run
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org