You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@jmeter.apache.org by se...@apache.org on 2012/09/12 02:11:08 UTC

svn commit: r1383688 - /jmeter/trunk/xdocs/usermanual/best-practices.xml

Author: sebb
Date: Wed Sep 12 00:11:08 2012
New Revision: 1383688

URL: http://svn.apache.org/viewvc?rev=1383688&view=rev
Log:
More on threads and variables

Modified:
    jmeter/trunk/xdocs/usermanual/best-practices.xml

Modified: jmeter/trunk/xdocs/usermanual/best-practices.xml
URL: http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/best-practices.xml?rev=1383688&r1=1383687&r2=1383688&view=diff
==============================================================================
--- jmeter/trunk/xdocs/usermanual/best-practices.xml (original)
+++ jmeter/trunk/xdocs/usermanual/best-practices.xml Wed Sep 12 00:11:08 2012
@@ -36,10 +36,19 @@
 <p>Your hardware's capabilities will limit the number of threads you can effectively
 run with JMeter.  It will also depend on how fast your server is (a faster server
  makes JMeter work harder since it returns request quicker).  The more
-JMeter works, the less accurate its timing information will be.  The more work
+JMeter works, the less accurate its timing information may become.  The more work
 JMeter does, the more each thread has to wait to get access to the CPU, the more
 inflated the timing information gets.  If you need large-scale load testing, consider
-running multiple non-GUI JMeter instances on multiple machines.</p>
+running multiple non-GUI JMeter instances on multiple machines. 
+The sample result files can be combined for subsequent analysis.
+For testing how JMeter performs on a given platform, the JavaTest sampler can be used.
+It does not require any network access so can give some idea as to the maximum throughput achievable.
+</p>
+<p>
+JMeter versions since 2.8 have an option to delay thread creation until the thread
+starts sampling, i.e. after any thread group delay and the ramp-up time for the thread itself.
+This allows for a very large total number of threads, provided that not too many are active concurrently.
+</p>
 </section>
 
 <section name="&sect-num;.2 Where to Put the Cookie Manager" anchor="put_cookie_manager">
@@ -324,5 +333,21 @@ In this case, don't use any User Defined
 the script and use them this way.
 </p>
 </section>
+
+<section name="&sect-num;.12 Sharing variables between threads and thread groups" anchor="sharing_variables">
+<p>
+Variables are local to a thread; a variable set in one thread cannot be read in another.
+This is by design. For variables that can be determined before a test starts, see 
+<a href="#parameterising_tests">Parameterising Tests</a> (above). 
+If the value is not known until the test starts, there are various options:
+<ul>
+<li>Store the variable as a property - properties are global to the JMeter instance</li>
+<li>Write variables to a file and re-read them.</li>
+<li>Use the bsh.shared namespace - see <a href="#bsh_variables">above</a></li>
+<li>Write your own Java classes</li>
+</ul>
+</p>
+</section>
+
 </body>
 </document>