You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by sebb <se...@gmail.com> on 2007/02/19 17:21:53 UTC
Re: Using JMeter over subnets 192.x.x.x or 10.x.x.x
On 19/02/07, Bruno Dillenseger <br...@orange-ftgroup.com> wrote:
> Lenin Basheer wrote:
> > There is a certain clause being mentioned in the tutorial for JMeter
> > Distributed testing procedure, that the server and clients are to be
> > in the same subnet while testing over subnets of the kind , 192.x.x.x
> > or 10.x.x.x
> Roughly speaking, these addresses are IPv4 private addresses which shall
> not be routed. So, in principle, the remote servers and the Jmeter
> master won't be able to reach each other. Unless you can put a routing
> machine configured to actually route between such subnets (don't know if
> it's feasible - it may depend on IP implementation), the only workaround
> I see is to use non-private addresses...
>
> Anyway, for your evaluation, note this is not a special issue with
> Jmeter. Any distributed load testing tool (or application in general)
> would have the same problem.
Well put.
Copying to JMeter user list (where the thread really belongs).
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Using JMeter over subnets 192.x.x.x or 10.x.x.x
Posted by sebb <se...@gmail.com>.
On 21/02/07, Lenin Basheer <Le...@ibsplc.com> wrote:
>
> Hi All,
[Please use plain text, not HTML]
> Thanks for your responses.
>
> I hope it means with Jmeter I just need to have the remote clients and the controlling client in the same subnet, irrespective of the server location and the subnet IP. Please correct me if I am wrong.
No.
They do not need to be in the same subnet, so long as there is a route
between the hosts.
The problem with the 192.x.x.x and 10.x.x.x addresses is that they may
not be routed.
> What i have been able to detect is anomalies in TPS calculation , which falls drastically with a client from another subnet is started. Your explaination is a fitting one , as it might not be able to contact the controlling client.
Please start a separate e-mail thread for this.
> But then the value stabilizes at times .. any reason why so ? Please note that the tool is being evaluated with a broader picture in view , as it will be used to performance test various data centers or mirrored servers or even bandwidth requirements.
>
> Just wanted to be sure with them , before i made the big leap.
>
> Thanks in advance for any help on this.
>
> best regards,
> Lenin
>
>
>
>
> sebb <se...@gmail.com>
>
> 02/19/2007 09:51 PM
>
> Please respond to
> "JMeter Developers List" <jm...@jakarta.apache.org>
>
>
> To"JMeter Developers List" <jm...@jakarta.apache.org>
>
> cc"JMeter Users List" <jm...@jakarta.apache.org>
>
> SubjectRe: Using JMeter over subnets 192.x.x.x or 10.x.x.x
>
>
>
>
>
>
>
>
> On 19/02/07, Bruno Dillenseger <br...@orange-ftgroup.com> wrote:
> > Lenin Basheer wrote:
> > > There is a certain clause being mentioned in the tutorial for JMeter
> > > Distributed testing procedure, that the server and clients are to be
> > > in the same subnet while testing over subnets of the kind , 192.x.x.x
> > > or 10.x.x.x
> > Roughly speaking, these addresses are IPv4 private addresses which shall
> > not be routed. So, in principle, the remote servers and the Jmeter
> > master won't be able to reach each other. Unless you can put a routing
> > machine configured to actually route between such subnets (don't know if
> > it's feasible - it may depend on IP implementation), the only workaround
> > I see is to use non-private addresses...
> >
> > Anyway, for your evaluation, note this is not a special issue with
> > Jmeter. Any distributed load testing tool (or application in general)
> > would have the same problem.
>
> Well put.
>
> Copying to JMeter user list (where the thread really belongs).
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
>
>
>
>
>
> DISCLAIMER:
>
> "The information in this e-mail and any attachment is intended only for the person to whom it is addressed and may contain confidential and/or privileged material. If you have received this e-mail in error, kindly contact the sender and destroy all copies of the original communication. IBS makes no warranty, express or implied, nor guarantees the accuracy, adequacy or completeness of the information contained in this email or any attachment and is not liable for any errors, defects, omissions, viruses or for resultant loss or damage, if any, direct or indirect."
>
>
>
>
>
> ---------------------------------------------------------------------
> 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: Using JMeter over subnets 192.x.x.x or 10.x.x.x
Posted by Lenin Basheer <Le...@ibsplc.com>.
Hi All,
Thanks for your responses.
I hope it means with Jmeter I just need to have the remote clients and the
controlling client in the same subnet, irrespective of the server location
and the subnet IP. Please correct me if I am wrong.
What i have been able to detect is anomalies in TPS calculation , which
falls drastically with a client from another subnet is started. Your
explaination is a fitting one , as it might not be able to contact the
controlling client.
But then the value stabilizes at times .. any reason why so ? Please note
that the tool is being evaluated with a broader picture in view , as it
will be used to performance test various data centers or mirrored servers
or even bandwidth requirements.
Just wanted to be sure with them , before i made the big leap.
Thanks in advance for any help on this.
best regards,
Lenin
sebb <se...@gmail.com>
02/19/2007 09:51 PM
Please respond to
"JMeter Developers List" <jm...@jakarta.apache.org>
To
"JMeter Developers List" <jm...@jakarta.apache.org>
cc
"JMeter Users List" <jm...@jakarta.apache.org>
Subject
Re: Using JMeter over subnets 192.x.x.x or 10.x.x.x
On 19/02/07, Bruno Dillenseger <br...@orange-ftgroup.com>
wrote:
> Lenin Basheer wrote:
> > There is a certain clause being mentioned in the tutorial for JMeter
> > Distributed testing procedure, that the server and clients are to be
> > in the same subnet while testing over subnets of the kind , 192.x.x.x
> > or 10.x.x.x
> Roughly speaking, these addresses are IPv4 private addresses which shall
> not be routed. So, in principle, the remote servers and the Jmeter
> master won't be able to reach each other. Unless you can put a routing
> machine configured to actually route between such subnets (don't know if
> it's feasible - it may depend on IP implementation), the only workaround
> I see is to use non-private addresses...
>
> Anyway, for your evaluation, note this is not a special issue with
> Jmeter. Any distributed load testing tool (or application in general)
> would have the same problem.
Well put.
Copying to JMeter user list (where the thread really belongs).
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
DISCLAIMER:
"The information in this e-mail and any attachment is intended only for
the person to whom it is addressed and may contain confidential and/or
privileged material. If you have received this e-mail in error, kindly
contact the sender and destroy all copies of the original communication.
IBS makes no warranty, express or implied, nor guarantees the accuracy,
adequacy or completeness of the information contained in this email or any
attachment and is not liable for any errors, defects, omissions, viruses
or for resultant loss or damage, if any, direct or indirect."