You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Sonam Chauhan <so...@ce.com.au> on 2007/10/31 08:07:08 UTC
HTTPClient [ Was RE: DNS round robin and JVM DNS lookup caching ]
Thanks Sebb:
I opened this enhancement request for the original DNS caching issue:
http://issues.apache.org/bugzilla/show_bug.cgi?id=43730
> > clients, shouldn't this setting be disobeyed? For instance, suppose
> > JMeter emulates 10 concurrent clients (10 threads) simultaneously
> > executing a slow webservice - would 5 connections be made first, and
the
> > latter connections be made as the first batch finishes?
>
> No idea. Threads could well interact this way.
>
> This is one of the reasons that we added the HttpClient sampler, which
> gives full control over connection re-use.
So does the standard 'HTTP Request' sampler use the built-in Java HTTP
implementation which is (probably) subject to these limits? If so, I
have a problem :D ... our automated test suite has more than 100 JMX
testscripts using 'HTTP Request', and not 'HTTP Request HTTPClient'.
JMeter Ver 2.1.1. (which we use) application help for 'HTTP Request' and
'HTTP Request HTTPClient' states:
"There are two versions of the sampler - one uses the default
Java HTTP implementation, the other uses Commons HttpClient"
... so I didn't know the differences. The 'Samplers' section of the user
manual does not mention the difference either:
http://jakarta.apache.org/jmeter/usermanual/test_plan.html#samplers
Is there any more current documentation on HTTPClient?
As these tests don't take the Java limits into account, should I shift
them to HTTPClient? The GUI interface for HTTP Request and HTTP Request
HTTPClient seems identical - so instead of editing all those testcases,
is it possible to manipulate the JMX XML by doing a search and replace
en-masse for the sampler name?
I've also opened enhancement request for the original issue:
http://issues.apache.org/bugzilla/show_bug.cgi?id=43730
Kind regards,
Sonam Chauhan
--
Corporate Express Australia Ltd.
Phone: +61-2-93350725, Email: sonam.chauhan@ce.com.au
-----Original Message-----
From: sebb [mailto:sebbaz@gmail.com]
Sent: Tuesday, 30 October 2007 10:11 PM
To: JMeter Users List
Subject: Re: DNS round robin and JVM DNS lookup caching
On 30/10/2007, Sonam Chauhan <so...@ce.com.au> wrote:
> Thanks Sebb. I'll put in a enhancement request.
>
> Regarding this:
>
>
> > > A probable precedent for this (I think) is that JMeter overrides
> this
> > > property too:
> > > ----------------------
> > > http.maxConnections (default: 5)
> > > If HTTP keep-alive is enabled, this value is the number of idle
> > > connections that will be simultaneously kept alive,
per-destination.
> >
> > I could not find where this is overridden in JMeter.
>
> I was speculating and just assumed it was overridden.
>
> I may have misunderstood the meaning of this setting, but is this the
> total number of HTTP connections between JMeter and a server (when
HTTP
> Keep-Alive is enabled as in HTTP 1.1)? Since JMeter is emulating many
> clients, shouldn't this setting be disobeyed? For instance, suppose
> JMeter emulates 10 concurrent clients (10 threads) simultaneously
> executing a slow webservice - would 5 connections be made first, and
the
> latter connections be made as the first batch finishes?
No idea. Threads could well interact this way.
This is one of the reasons that we added the HttpClient sampler, which
gives full control over connection re-use.
> Kind regards,
> Sonam Chauhan
> --
> Corporate Express Australia Ltd.
> Phone: +61-2-93350725, Email: sonam.chauhan@ce.com.au
>
> -----Original Message-----
> From: sebb [mailto:sebbaz@gmail.com]
> Sent: Friday, 26 October 2007 10:00 PM
> To: JMeter Users List
> Subject: Re: DNS round robin and JVM DNS lookup caching
>
> On 26/10/2007, Sonam Chauhan <so...@ce.com.au> wrote:
> > Thanks for the comprehensive response (as always) Sebb.
> >
> > > The default TTL is -1, for the reasons stated in the bug report.
> > > This means the cached value will be kept for the life of the JVM.
> >
> > Sun is wrong in their reasoning here (and frustratingly so) - if
they
> > wanted to cache DNS properly, they should have cached entries only
for
> > their TTL duration. Even browsers don't cache forever by default!
>
> There is no reasoning stated in the java.properties file - they just
> assert that it is necessary to permanently cache any DNS results when
> there is a security manager.
>
> They are deliberately overriding the TTL. It's not clear why this
> protects against DNS spoofing - the first DNS result may be spoofed -
> but it does mean that the IP address cannot change once obtained,
> which may be important for some unstated reasons.
>
> > ---------------------
> > From
http://en.wikipedia.org/wiki/Domain_name_system#Broken_resolvers
> >
> > As a final level of complexity, some applications (such as
> web-browsers)
> > also have their own DNS cache, in order to reduce the use of the DNS
> > resolver library itself. This practice can add extra difficulty when
> > debugging DNS issues, as it obscures the freshness of data, and/or
> what
> > data comes from which cache. These caches typically use very short
> > caching times - of the order of one minute. Internet Explorer offers
a
> > notable exception: recent versions cache DNS records for half an
> > hour.[1]
> > ---------------------
> >
> > Do you think it's worth a Bugzilla feature request for JMeter allow
> the
> > user to override Java's default DNS-caching behaviour in a
> user-setting
> > at the beginning of the test? This will enable it to work properly
(as
> a
> > browser would) in DNS round-robin load balancing scenario.
>
> You can already do this for Sun JVMs - just define
> sun.net.inetaddr.ttl on the command-line or in system.properties.
>
> But I suppose it would be possible for JMeter to treat the property
> networkaddress.cache.ttl specially, and set it as per the bug
> description.
>
> BTW, the file java.security seems to have the default as:
>
> security.overridePropertiesFile=true
>
> which means that the property java.security.properties can be used to
> append to/override the java.security file; this might make it
> unnecessary to special-case the TTL property.
>
> But it would be simpler for the user if it could be defined in the
> JMeter system.properties file, so feel free to create an enhancement
> request.
>
> > A probable precedent for this (I think) is that JMeter overrides
this
> > property too:
> > ----------------------
> > http.maxConnections (default: 5)
> > If HTTP keep-alive is enabled, this value is the number of idle
> > connections that will be simultaneously kept alive, per-destination.
>
> I could not find where this is overridden in JMeter.
>
> > ----------------------
> >
> > Kind regards,
> > Sonam Chauhan
> > --
> > Corporate Express Australia Ltd.
> > Phone: +61-2-93350725, Email: sonam.chauhan@ce.com.au
> >
> >
> >
> > -----Original Message-----
> > From: sebb [mailto:sebbaz@gmail.com]
> > Sent: Thursday, 25 October 2007 10:07 PM
> > To: JMeter Users List
> > Subject: Re: DNS round robin and JVM DNS lookup caching
> >
> > The Sun Java document is at:
> >
> > http://java.sun.com/j2se/1.4.2/docs/guide/net/properties.html
> >
> > which says you can change networkaddress.cache.ttl in java.security
or
> > sun.net.inetaddr.ttl on the command-line.
> >
> > These need to be defined at startup - or at least before DNS is
first
> > used.
> >
> > So you cannot change the TTL without restarting, but you can set it
to
> > a low enough value (try 0) such that DNS queries are not cached for
> > too long.
> >
> > The default TTL is -1, for the reasons stated in the bug report.
> > This means the cached value will be kept for the life of the JVM.
> >
> > I think non-Java applications also cache DNS results; I'm not sure
if
> > this is done in the language library or the OS itself.
> >
> > Nor do I know if Java is subject to caching of DNS entries by the
OS.
> >
> > If you want to sure of using the correct DNS entries, you could
> > perhaps try using CSV Dataset with a file of IP addresses. However
> > this probably won't work for virtual hosts, as they normally require
> > the host name (and I'm not sure you can override this via the header
> > manager).
> >
> > On 25/10/2007, Sonam Chauhan <so...@ce.com.au> wrote:
> > > Hi -
> > >
> > >
> > >
> > > I've got to load test a clustered application server.
> > >
> > >
> > >
> > > External users of the application (whom JMeter must simulate)
access
> > it
> > > through a hardware load balancer.
> > >
> > >
> > >
> > > However, internal access goes through DNS Round Robin load
balancing
> > > (implemented in Active Directory). This means that each DNS
request
> to
> > > resolve a hostname will resolve to a different primary IP address.
> > >
> > >
> > >
> > > I understand that the JVM caches DNS lookups forever by default.
> This
> > > article implies that a JMeter load test accessing a cluster
through
> > the
> > > DNS Round Robin above, will only load test 1 node in the cluster
as
> it
> > > caches the first name resolution it does:
> > >
> > > http://www.rgagnon.com/javadetails/java-0445.html
> > >
> > > Once an application has performed network access (i.e.
> urlconnection,
> > > parsing of xml document with external references, etc), the DNS
> > settings
> > > get cached so any subsequent operation will use the old settings
> even
> > if
> > > the real settings have changed. To reset everything, you have to
> > restart
> > > the server since the default setting JVM setting is to cache
> forever.
> > >
> > >
> > > Is this true? How does this impact JMeter testing? I found this
> > related
> > > bug on the Sun website.
> > >
> > >
> > >
> > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6376406
> > >
> > >
> > >
> > >
> > >
> > > Kind regards,
> > >
> > > Sonam Chauhan
> > >
> > > --
> > >
> > > Corporate Express Australia Ltd.
> > >
> > > Phone: +61-2-93350725, Email: sonam.chauhan@ce.com.au
> > >
> > >
> > >
> > >
> >
> >
---------------------------------------------------------------------
> > 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
> >
> >
>
> ---------------------------------------------------------------------
> 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
>
>
---------------------------------------------------------------------
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: HTTPClient [ Was RE: DNS round robin and JVM DNS lookup caching ]
Posted by sebb <se...@gmail.com>.
On 31/10/2007, Sonam Chauhan <so...@ce.com.au> wrote:
> Thanks Sebb:
>
> I opened this enhancement request for the original DNS caching issue:
> http://issues.apache.org/bugzilla/show_bug.cgi?id=43730
>
OK, seen it
> > > clients, shouldn't this setting be disobeyed? For instance, suppose
> > > JMeter emulates 10 concurrent clients (10 threads) simultaneously
> > > executing a slow webservice - would 5 connections be made first, and
> the
> > > latter connections be made as the first batch finishes?
> >
> > No idea. Threads could well interact this way.
> >
> > This is one of the reasons that we added the HttpClient sampler, which
> > gives full control over connection re-use.
>
> So does the standard 'HTTP Request' sampler use the built-in Java HTTP
> implementation which is (probably) subject to these limits? If so, I
Yes.
> have a problem :D ... our automated test suite has more than 100 JMX
> testscripts using 'HTTP Request', and not 'HTTP Request HTTPClient'.
Whether you have a problem depends on what you are trying to prove
with the tests, and whether the Java implementation restrictions have
any measurable impact on the tests.
If you suspect a JVM limit is having an effect, try splitting a test
into two or more concurrent separate tests and see if there is a
noticeable difference.
Also you may be able to try changing the Java parameters to suit your tests.
> JMeter Ver 2.1.1. (which we use) application help for 'HTTP Request' and
> 'HTTP Request HTTPClient' states:
> "There are two versions of the sampler - one uses the default
> Java HTTP implementation, the other uses Commons HttpClient"
> ... so I didn't know the differences. The 'Samplers' section of the user
> manual does not mention the difference either:
>
> http://jakarta.apache.org/jmeter/usermanual/test_plan.html#samplers
> Is there any more current documentation on HTTPClient?
http://jakarta.apache.org/httpcomponents/httpclient-3.x/
> As these tests don't take the Java limits into account, should I shift
> them to HTTPClient?
See above - are the limits causing a problem?
> The GUI interface for HTTP Request and HTTP Request
> HTTPClient seems identical - so instead of editing all those testcases,
> is it possible to manipulate the JMX XML by doing a search and replace
> en-masse for the sampler name?
Yes, see ConvertHTTPSampler.txt in the extras/ directory.
You'll need to get this from a later version of JMeter or SVN.
However, there have been a lot of improvements to the JMeter
HttpClient code since 2.1.1, and the library itself has been updated,
so I would recommend updating JMeter to 2.3 as well.
> I've also opened enhancement request for the original issue:
> http://issues.apache.org/bugzilla/show_bug.cgi?id=43730
>
> Kind regards,
> Sonam Chauhan
> --
[snip]
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org