On 30/10/2007, Sonam Chauhan <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > -----Original Message----- > From: sebb [mailto:[EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > > > > > > > -----Original Message----- > > From: sebb [mailto:[EMAIL PROTECTED] > > 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
