mstover1 01/03/24 12:44:25
Modified: bin jmeter.bat
docs bugs.html changes.html
docs/extending index.html
docs/user_manual rmi.html
xdocs bugs.xml changes.xml
xdocs/extending index.xml
xdocs/user_manual rmi.xml
Log:
More documentation in preparation for 1.6alpha release
Revision Changes Path
1.12 +1 -2 jakarta-jmeter/bin/jmeter.bat
Index: jmeter.bat
===================================================================
RCS file: /home/cvs/jakarta-jmeter/bin/jmeter.bat,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- jmeter.bat 2001/02/19 02:37:20 1.11
+++ jmeter.bat 2001/03/24 20:44:22 1.12
@@ -11,5 +11,4 @@
IF "%5" EQU "-f" set PROP=%6
IF "%5" EQU "-h" set HOST=-Dhttp.proxyHost=%6
IF "%5" EQU "-p" set PORT=-Dhttp.proxyPort=%6
-java -cp %CLASSPATH%;../lib/xerces.jar;ApacheJMeter.jar %HOST% %PORT%
-org.apache.jmeter.NewDriver %PROP%
+java -cp %CLASSPATH%;../lib/xerces.jar;ApacheJMeter.jar %HOST% %PORT%
org.apache.jmeter.NewDriver %PROP%
1.9 +3 -5 jakarta-jmeter/docs/bugs.html
Index: bugs.html
===================================================================
RCS file: /home/cvs/jakarta-jmeter/docs/bugs.html,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- bugs.html 2001/03/17 22:25:39 1.8
+++ bugs.html 2001/03/24 20:44:22 1.9
@@ -76,11 +76,9 @@
</td></tr>
<tr><td>
<blockquote>
- <ul>
- <li>The scrolling bar of the graphical plot visualizer has fixed size.</li>
- <li>Thread overload may false results due to garbage collection interference.</li>
- <li>Code design in not as good as it should be, as usual ;-).</li>
-</ul>
+ <p>
+JMeter 1.6Alpha is just out. There are no known bugs currently (but plenty of
things
+to do still)</p>
</blockquote>
</td></tr>
</table>
1.22 +12 -18 jakarta-jmeter/docs/changes.html
Index: changes.html
===================================================================
RCS file: /home/cvs/jakarta-jmeter/docs/changes.html,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- changes.html 2001/03/17 22:25:39 1.21
+++ changes.html 2001/03/24 20:44:22 1.22
@@ -80,24 +80,19 @@
<b>Changes are chronologically ordered from top (most recent) to bottom
(least recent)</b>
</p>
- <p>
-<b>Apache JMeter 1.5.1</b>
-</p>
- <p>
-<b>Contributors</b> - If I missed any, please let me know (<a
href="mail:[EMAIL PROTECTED]">
-Michael Stover</a>):
-<ul>
- <li>Brendan Burns</li>
- <li>Michael Stover</li>
- <li>Jeff Pajor</li>
- <li>Tom Wiedenhoeft</li>
- <li>Matthew Daniel</li>
- <li>Steve Gentle</li>
- <li>Tom Schneider</li>
+ <b>Changes:</b>
+ <h3>Version 1.6 Alpha</h3>
+ <ul>
+<li>New UI</li>
+<li>Separation of GUI and Logic code</li>
+<li>New Plug-in framework for new modules</li>
+<li>Enhanced performance</li>
+<li>Layering of test logic for greater flexibility</li>
+<li>Added support for saving of test elements</li>
+<li>Added support for distributed testing using a single client</li>
</ul>
-<b>Changes:</b>
-<h3>Version 1.5.1</h3>
-<ul>
+ <h3>Version 1.5.1</h3>
+ <ul>
<li>Fixed bug that caused cookies not to be read if header name case not as
expected.</li>
<li>Clone entries before sending to sampler - prevents relocations from messing up
information across threads</li>
<li>Minor bug fix to convenience dialog for adding paramters to test sample. Bug
prevented entries in dialog from appearing in test sample.</li>
@@ -106,7 +101,6 @@
<li>Started work on new framework. New files in cvs, but do not effect program
yet.</li>
<li>Fixed bug that prevent HTTPJMeterThread from delaying according to chosen
timer.</li>
</ul>
-</p>
<p>
<h3>Version 1.5</h3>
<ul>
1.3 +78 -62 jakarta-jmeter/docs/extending/index.html
Index: index.html
===================================================================
RCS file: /home/cvs/jakarta-jmeter/docs/extending/index.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- index.html 2001/03/24 14:39:57 1.2
+++ index.html 2001/03/24 20:44:23 1.3
@@ -81,15 +81,17 @@
to make this task easier.
</p>
<ul>
- <li>Creating your own Timer</li>
- <li>Creating your own SampleListener (such as a visualizer, or reporter)</li>
- <li>Creating your own Config Element</li>
- <li>Creating your own logic SamplerController</li>
- <li>Creating your own test sample SamplerController</li>
- <li>Creating your own Sampler</li>
- <li>Making your custom elements play nice as a JMeter UI component</li>
- <li>Making your custom elements saveable and loadable from within JMeter</li>
+ <li><a href="#timer">Creating your own Timer</a></li>
+ <li><a href="#listener">Creating your own SampleListener (such as a
visualizer, or reporter)</a></li>
+ <li><a href="#config">Creating your own Config Element</a></li>
+ <li><a href="#logical">Creating your own logic SamplerController</a></li>
+ <li><a href="#testsample">Creating your own test sample
SamplerController</a></li>
+ <li><a href="#sampler">Creating your own Sampler</a></li>
+ <li><a href="#uicomponent">Making your custom elements play nice as a JMeter
UI component</a></li>
+ <li><a href="#saveable">Making your custom elements saveable and loadable from
within JMeter</a></li>
</ul>
+ <hr />
+ <a name="timer" />
<h3>Creating your own Timer</h3>
<p>The timer interface:</p>
<pre>
@@ -99,6 +101,8 @@
long representing the number of milliseconds to delay. The constant timer returns
the
same number every time it's called. A random timer returns a different number each
time.
</p>
+ <hr />
+ <a name="listener" />
<h3>Creating your own
SampleListener</h3>
<p>The SampleListener interface:</p>
<pre>
@@ -117,6 +121,8 @@
(ie, they are running and waiting for response, or they're stopped and waiting
to begin again).
</p>
+ <hr />
+ <a name="config" />
<h3>Creating your own Config
Element</h3>
<p>The ConfigElement interface:</p>
<pre>
@@ -125,19 +131,19 @@
public Object clone();
</pre>
<p>The ConfigElement interface is
sparse. All ConfigElements are expected to implement
-a public clone method. The reason for this is that config elements will be cloned
+a public <b>clone()</b> method. The reason for this is that config elements will
be cloned
for each different sampling thread, and most will be cloned for each sample. </p>
<p>If your config element expects
to be modified in the process of a test run,
and you want those modifications to carry over from sample to sample (as in
a cookie manager - you want to save all cookies that gets set throughout
-the test), then return true for this method. Your config element will not be
+the test), then return true for the <b>expectsModification()</b> method. Your
config element will not be
cloned for each sample. If your config elements are more static in nature,
return false. If in doubt, return false.</p>
- <p>The addConfigElement is required
so that config elements can be layered. For
+ <p><b>addConfigElement()</b> is
required so that config elements can be layered. For
instance, let's say a user creates a URL entry that contains default values -
they might use this to specify a server. Then, all their test samples configure
individual test cases, but leave out the server field. This information is combined
-via the addConfigElement method. Your custom config elements should do the right
+via the <b>addConfigElement()</b> method. Your custom config elements should do
the right
thing when this method is called. Normally, this involves ignoring such calls
unless
the passed in ConfigElement is of the same type as yours, and then only merging in
values that are not already set in the object receiving the call (ie you probably
@@ -149,12 +155,12 @@
in your config element. The sampler that uses your config element needs to know
more
about the class than the rest of JMeter - that information is not part of this
interface.
</p>
- <p>If at all possible, extend
AbstractConfigElement when creating your own. By doing so,
+ <p>If at all possible, extend
<b>AbstractConfigElement</b> when creating your own. By doing so,
and by following some simple rules, you will get cloning and saving to XML of your
-config element for free (as in, you don't have to do anything!).
AbstractConfigElement
+config element for free (as in, you don't have to do anything!).
<b>AbstractConfigElement</b>
stores all it's values in a Map, and provides getProperty and putProperty methods.
Your
-config element can provide getXXX() and setXXX() methods, but these should delegate
-to getProperty() and setProperty(), probably using static Strings as keys in the
Map.
+config element can provide <b>getXXX()</b> and <b>setXXX()</b> methods, but these
should delegate
+to <b>getProperty()</b> and <b>setProperty()</b>, probably using static Strings as
keys in the Map.
<br />You can store any type of object, provided the objects are clonable and
Saveable
(Strings, Integer, Long, Double, Float are all good in this regard).
</p>
@@ -164,6 +170,8 @@
have to be converted from a String to an int, so your getXXX() method should check
for this possibility to avoid exceptions.
</p>
+ <hr />
+ <a name="logical" />
<h3>Creating your own logic
SamplerController</h3>
<p>The SamplerController interface
looks as follows:</p>
<pre>
@@ -177,7 +185,7 @@
contamination between sampling threads.</p>
<p>The <b>nextEntry()</b> method is
the essential job of a SamplerController - to deliver
Entry objects to be sampled. An Entry object encapsulates all the information
needed
-by a Sampler to do its job. The nextEntry() method should work like an iterator and
+by a Sampler to do its job. The <b>nextEntry()</b> method should work like an
iterator and
continuously return new Entry objects.
</p>
<p>There are two boundary
conditions that need to be handled. If the Controller has no
@@ -210,17 +218,21 @@
<p><b>addConfigElement(ConfigElement config)</b> Your SamplerController should also
be capable of holding configuration elements and adding them to Entries as they
pass through your controller. Again, see GenericController for reference.
Essentially,
-all Entry objects that get returned by nextEntry() are handed all the ConfigElements
+all Entry objects that get returned by <b>nextEntry()</b> are handed all the
ConfigElements
of the controller.
</p>
- <h3>Creating your own test sample
SampleController</h3>
+ <hr />
+ <a name="testsample" />
+ <h3>Creating your own test sample
SamplerController</h3>
<p>A SamplerController that
generates Entry objects is just like a logic controller
except that it creates its own Entry objects instead of gathering them from
-sub-controllers (although, to be fully correct, your test sample SampleController
-should handle both possibilities). Your test sample SampleController can also
+sub-controllers (although, to be fully correct, your test sample SamplerController
+should handle both possibilities). Your test sample SamplerController can also
benefit from extending GenericController. By doing so, most of your cloning and
saving needs are handled (but probably not entirely). See HttpTestSample as
reference.</p>
+ <hr />
+ <a name="sampler" />
<h3>Creating your own Sampler</h3>
<p>The Sampler interface:</p>
<pre>
@@ -229,10 +241,12 @@
<p>Your Sampler has two
responsibilities. Of lesser importance, it should do whatever
it is you want to do, given an Entry object that hopefully contains information
about what is to be sampled. Of greater importance, your sampler should return
-a SampleResult object that holds information about the sampling. Information such
+a <b>SampleResult</b> object that holds information about the sampling.
Information such
as how long the sample took, the text response from the sample (if appropriate), and
a string that describes the location of what was sampled. The SampleResult
interface
is essentially a Map with public static Strings as keys. </p>
+ <hr />
+ <a name="uicomponent" />
<h3>Making your custom elements
play nice as a JMeter UI component</h3>
<p>In order to take part in the
JMeter UI, your component needs to implement the
JMeterComponentModel interface:</p>
@@ -244,18 +258,18 @@
public String getClassLabel();
public void uncompile();
</pre>
- <p>Most of this stuff is easy,
boring, and tedious. getName(), setName() is a simple
-String property that is the name of the object. getClassLabel() should return
+ <p>Most of this stuff is easy,
boring, and tedious. <b>getName()</b>, <b>setName()</b> is a simple
+String property that is the name of the object. <b>getClassLabel()</b> should
return
a String that describes the class. This string will be displayed to the user and
-so should be short but meaningful. getGuiClass() should return a Class object for
+so should be short but meaningful. <b>getGuiClass()</b> should return a Class
object for
the class that will be used as a GUI component. This class should be a subclass
-of java.awt.Container, and preferably a subclass of javax.swing.JComponent.</p>
+of java.awt.Container, and preferably a subclass of
<b>javax.swing.JComponent</b>.</p>
<p><b>getAddList()</b> should
return a list of either Strings or JMenus. These Strings
represent the Classes that can be added to your SamplerController. Each String
-should correspond to the target class's getClassLabel() String. MenuFactory is
+should correspond to the target class's <b>getClassLabel()</b> String.
<b>MenuFactory</b> is
a class that will return some preset menu lists (such as all available
SamplerControllers,
all available ConfigElements, etc).</p>
- <p><b>uncompile</b> is a cleanup
method used between sampling runs. When the user
+ <p><b>uncompile()</b> is a cleanup
method used between sampling runs. When the user
hits "Start", JMeter "compiles" the objects in the tree. Child nodes are added
to their parent objects recursively until there is one TestPlan object, which is
then submitted for testing. Afterward, these elements have to un-added from their
@@ -265,25 +279,27 @@
<p>That's it, except for your GUI
class. If your SamplerController has no
configuration needs, just return org.apache.jmeter.gui.NamePanel, and the user will
at least be able to change the name of your component. Otherwise, create a gui
class
-that implements the ModelSupported interface:</p>
+that implements the <b>ModelSupported</b> interface:</p>
<pre>
void setModel(Object model);
public void updateGui();
</pre>
- <p>setModel is used to hand your
JMeterModelComponent class to the GUI class when
+ <p><b>setModel()</b> is used to
hand your JMeterModelComponent class to the GUI class when
it is instantiated. It is your responsibility for providing the means by which
the Gui class updates the values in the model class. For updating in the other
direction, there is <b>updateGui()</b>, which the model class can call if necessary.
Note, normally, this call is made for you automatically whenever the Gui is brought
-to the screen. If you are creating a Visualizer, then you may need to use
updateGui().
+to the screen. If you are creating a Visualizer, then you may need to use
<b>updateGui()</b>.
For reference, refer to UrlConfigGui (in
org.apache.jmeter.protocol.http.config.gui).</p>
<p>If you have done all this
correctly, there's just one more step. If you compile
your classes into the ApacheJMeter.jar file, then you're done. Your classes will
be automatically found and used. Otherwise, you will need to modify
jmeter.properties.
The <i>search_paths</i> property should be modified to include the path where your
classes are. This does not obviate the need for your classes to be in the JVM's
-CLASSPATH - it is an additional requirement. Otherwise, your classes will be
+CLASSPATH - it is an additional requirement. Otherwise, your classes will not be
detected, and the Gui will not make them available to the user.</p>
+ <hr />
+ <a name="saveable" />
<h3>Making your custom elements
saveable and loadable from within JMeter</h3>
<p>The Saveable interface has just
one method:</p>
<pre>
@@ -291,9 +307,9 @@
</pre>
<p>This method simply returns the
Class object that represents the Class that handles
the saving and loading of your component.</p>
- <p>To write this SaveHandler, make
a class that extends TagHandler
+ <p>To write this SaveHandler, make
a class that extends <b>TagHandler</b>
(from org.apache.jmeter.save.xml). Note, if your component extends
AbstractConfigElement,
-you don't need to do this - provided you only need to save information stored in
+it is already fully Saveable - provided you only have information stored in
the Map from AbstractConfigElement.</p>
<p>To write your own TagHandler,
you will have to implement the following methods:</p>
<pre>
@@ -317,14 +333,14 @@
an XML file. However, there's no standard interface you need to implement, but
rather,
JMeter uses reflection to generate method calls into your class. When JMeter hits
a tag that corresponds to your PrimaryTagName, an instance of your TagHandler will
-be created, and it's setAtts() method will get called. Thereafter, methods are
called
+be created, and it's <b>setAtts()</b> method will get called. Thereafter, methods
are called
depending on subsequent tags and character data. For every tag, JMeter calls
-<tag-name>TagStart(Attributes atts), and for every end tag, JMeter calls
-<tag-name>TagEnd().</p>
+<b><tag-name>TagStart(Attributes atts)</b>, and for every end tag, JMeter
calls
+<b><tag-name>TagEnd()</b>.</p>
<p>Additionally, JMeter will call a
method that corresponds to all tags that are
current. So, for instance, if JMeter runs into a tag name "foo", then
<b>foo(Attributes atts)</b> will be called. If JMeter then parses character data,
-then foo(String data) will be called. If JMeter parses a tag within foo, called
+then <b>foo(String data)</b> will be called. If JMeter parses a tag within foo,
called
"nestedFoo", then JMeter will call <b>foo_nestedFoo(Attributes atts)</b> and
<b>foo_nestedFoo(String data)</b>. And so on.
</p>
@@ -339,40 +355,40 @@
{
}
- /**
+ <font color="blue">/**
* Returns the AbstractConfigElement object parsed from the XML. This method
* is required to fulfill the SaveHandler interface. It is used by the XML
* routines to gather all the saved objects.
- */
+ */</font>
public Object getModel()
{
return config;
}
- /**
+ <font color="blue">/**
* This is called when a tag is first encountered for this handler class to
handle.
* The attributes of the tag are passed, and the SaveHandler object is expected
* to instantiate a new object.
- */
+ */</font>
public void setAtts(Attributes atts) throws Exception
{
String className = atts.getValue("type");
config = (AbstractConfigElement)Class.forName(className).newInstance();
}
- /**
+ <font color="blue">/**
* Called by reflection when a <property> tag is encountered. Again, the
* attributes are passed.
- */
+ */</font>
public void property(Attributes atts)
{
currentProperty = atts.getValue("name");
}
- /**
+ <font color="blue">/**
* Called by reflection when text between the begin and end <property>
* tag is encountered.
- */
+ */</font>
public void property(String data)
{
@@ -383,12 +399,12 @@
}
}
- /**
+ <font color="blue">/**
* Called by reflection when the <property> tag is ended.
- */
+ */</font>
public void propertyTagEnd()
{
- // Here's a tricky bit. See below for explanation.
+ <font color="blue">// Here's a tricky bit. See below for
explanation.</font>
List children = xmlParent.takeChildObjects(this);
if(children.size() == 1)
{
@@ -397,17 +413,17 @@
}
- /**
+ <font color="blue">/**
* Gets the tag name that will trigger the use of this object's TagHandler.
- */
+ */</font>
public String getPrimaryTagName()
{
return "ConfigElement";
}
- /**
+ <font color="blue">/**
* Tells the object to save itself to the given output stream.
- */
+ */</font>
public void save(Saveable obj,Writer out) throws IOException
{
AbstractConfigElement saved = (AbstractConfigElement)obj;
@@ -424,9 +440,9 @@
out.write(</ConfigElement>");
}
- /**
+ <font color="blue">/**
* Routine to write each property to xml.
- */
+ */</font>
private void writeProperty(Writer out,String key,Object value) throws
IOException
{
out.write("<property name=\"");
@@ -437,18 +453,18 @@
}
</pre>
<p>
-In the propertyTagEnd method, takeChildObjects() is called on the xmlParent
-instance variable. xmlParent is inherited from TagHandler. It is the
DocumentHandler
+In the <b>propertyTagEnd()</b> method, <b>takeChildObjects()</b> is called on the
xmlParent
+instance variable. xmlParent is inherited from TagHandler - the DocumentHandler
object that is running the show. xmlParent takes an XML file that represents a
portion of
the test configuration tree, and recreates a tree-like data structure. When it is
done, it will convert its tree-like data structure into the test configuration tree
structure.
</p>
<p>However, sometimes, a tree
element has sub objects that you do not want represented
-in the tree - rather, they are objects that are part of your object. But, they may
+in the tree - rather, they are part of your object. But, they may
be complicated enough to warrant their own SaveHandler class, and thus, the
xmlParent
picks them up as part of its tree. When the tag is done, and you know that there
are
-child objects you want to grab, you can call the "takeChildObjects" method and get a
+child objects you want to grab, you can call the <b>takeChildObjects()</b> method
and get a
List object containing them all. This will remove them from the tree, and you can
add
them to your object that you're creating.
</p>
@@ -457,9 +473,9 @@
code above to save and reload itself from XML. However, one of the pieces of data
that UrlConfig stores is an Arguments object. Arguments is too complicated to save
to file as a simple string, so it has its own Handler object (ArgumentsHandler). In
-the above code, when the call to JMeterHandler.writeObject(value,out) is made, the
+the above code, when the call to <b>JMeterHandler.writeObject(value,out)</b> is
made, the
writeObject method detects whether the object implements Saveable, and if so, calls
-the object's SaveHandler class to handle saving it. This means, however, that when
+the object's SaveHandler class to deal with it. This means, however, that when
reading that XML file, the Argument object will show up as a separate entity in
the data tree, whereas it originally was just part of the data of the UrlConfig
object. In order to preserve that relationship, it's necessary for the
@@ -467,7 +483,7 @@
objects in the tree, and take them for its own use.
</p>
<p>
-Please study the other SaveHandler objects and the TagHandler class to learn more
+Study the other SaveHandler objects and the TagHandler class to learn more
about how saving is accomplished. Once you understand the design, writing your
own SaveHandler is very easy.
</p>
1.2 +27 -27 jakarta-jmeter/docs/user_manual/rmi.html
Index: rmi.html
===================================================================
RCS file: /home/cvs/jakarta-jmeter/docs/user_manual/rmi.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- rmi.html 2001/03/24 14:39:58 1.1
+++ rmi.html 2001/03/24 20:44:23 1.2
@@ -78,22 +78,22 @@
<blockquote>
<p>
In most real world web application environments the machine running the web
-application is not the machine which is sitting on your desk. However to
-get a true estimate of performance you would like to be measuring the
-true response time of your server, not any (highly variable) network
-bottle-necks that might exist between you and the machine on which your web
-application is running. At the same time using a GUI especially a Java
-GUI over the network is at best painful (using Un*x and X) and at times not
+application is not the machine which is sitting on your desk. However to
+get a true estimate of performance you would like to be measuring the
+true response time of your server, not any (highly variable) network
+bottle-necks that might exist between you and the machine on which your web
+application is running. At the same time using a GUI especially a Java
+GUI over the network is at best painful (using Un*x and X) and at times not
possible (using windows).
</p>
<p>
-To solve this problem JMeter provides a client-server architecture for load
-and performance testing which allows the JMeterEngine (the tester) to
-reside and run on your application server while the configuration GUI and
-visualization executes on the development machine. This offers a number
+To solve this problem JMeter provides a client-server architecture for load
+and performance testing which allows the JMeterEngine (the tester) to
+reside and run on your application server while the configuration GUI and
+visualization executes on the development machine. This offers a number
of features:
<ul>
- <li>True performance measurment without network bottlenecks</li>
+ <li>True performance measurment without network bottlenecks</li>
<li>Fast responsive GUI</li>
<li>Saving of test samples to a local machine</li>
<li>Managment of multiple JMeterEngines from a single machine</li>
@@ -111,14 +111,14 @@
<tr><td>
<blockquote>
<p>
-Follow the <a href="installing.html">instructions</a> for installing
-JMeter. Once JMeter is sucessfully installed you will need to put the
-<code>.../JMeter1.6/bin/ApacheJMeter.jar</code> into your
-<code>CLASSPATH</code> environment variable and execute
-<code>rmiregistry</code>. Once the RMI registry is started you will need
-to start the actual JMeterServer. To do this run the
-<code>jmeter-server</code> (Un*x) or <code>jmeter-server.bat</code>
-script (windows) to start the server. Your server should now be started,
+Follow the <a href="installing.html">instructions</a> for installing
+JMeter. Once JMeter is sucessfully installed you will need to put the
+<code>.../JMeter1.6/bin/ApacheJMeter.jar</code> into your
+<code>CLASSPATH</code> environment variable and execute
+<code>rmiregistry</code>. Once the RMI registry is started you will need
+to start the actual JMeterServer. To do this run the
+<code>jmeter-server</code> (Un*x) or <code>jmeter-server.bat</code>
+script (windows) to start the server. Your server should now be started,
to test it follow the instructions for running the JMeter client.
</p>
</blockquote>
@@ -133,14 +133,14 @@
<tr><td>
<blockquote>
<p>
-Once JMeter is sucessfully installed you need to modify the
-<code>jmeter.properties</code> file in the bin directory. Change the
-<code>remote_hosts</code> property to include the address of your server.
-Next run <code>jmeter-client</code> (Un*x) or
-<code>jmeter-client.bat</code> (windows) to connect to the JMeter Engine.
-If everything works as planned you will be connected with the JMeter
-Engine and JMeter will behave exactly as if you were running it all
-locally. See the <a href="user_manual/index.html">user manual</a> for
+Once JMeter is sucessfully installed you need to modify the
+<code>jmeter.properties</code> file in the bin directory. Change the
+<code>remote_hosts</code> property to include the address of your server.
+Next run <code>jmeter</code> (Un*x) or
+<code>jmeter.bat</code> (windows) to connect to the JMeter Engine.
+If everything works as planned you will be connected with the JMeter
+Engine and JMeter will behave exactly as if you were running it all
+locally. See the <a href="user_manual/index.html">user manual</a> for
detailed instructions.
</p>
</blockquote>
1.2 +5 -7 jakarta-jmeter/xdocs/bugs.xml
Index: bugs.xml
===================================================================
RCS file: /home/cvs/jakarta-jmeter/xdocs/bugs.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- bugs.xml 2001/03/07 06:38:36 1.1
+++ bugs.xml 2001/03/24 20:44:23 1.2
@@ -1,16 +1,14 @@
<?xml version="1.0"?>
<document>
<properties>
- <author email="[EMAIL PROTECTED]">Brendan Burns, et al.</author>
- <title>Known Bugs</title>
+ <author email="[EMAIL PROTECTED]">Brendan Burns, et al.</author>
+ <title>Known Bugs</title>
</properties>
<body>
<section name="Known Bugs">
-<ul>
- <li>The scrolling bar of the graphical plot visualizer has fixed size.</li>
- <li>Thread overload may false results due to garbage collection
interference.</li>
- <li>Code design in not as good as it should be, as usual ;-).</li>
-</ul>
+<p>
+JMeter 1.6Alpha is just out. There are no known bugs currently (but plenty of
things
+to do still)</p>
</section>
</body>
</document>
1.2 +11 -15 jakarta-jmeter/xdocs/changes.xml
Index: changes.xml
===================================================================
RCS file: /home/cvs/jakarta-jmeter/xdocs/changes.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- changes.xml 2001/03/07 06:38:36 1.1
+++ changes.xml 2001/03/24 20:44:24 1.2
@@ -10,22 +10,18 @@
<b>Changes are chronologically ordered from top (most recent) to bottom
(least recent)</b>
</p>
-<p>
-<b>Apache JMeter 1.5.1</b>
-</p>
-<p>
-<b>Contributors</b> - If I missed any, please let me know (<a
href="mail:[EMAIL PROTECTED]">
-Michael Stover</a>):
+
+<b>Changes:</b>
+<h3>Version 1.6 Alpha</h3>
<ul>
- <li>Brendan Burns</li>
- <li>Michael Stover</li>
- <li>Jeff Pajor</li>
- <li>Tom Wiedenhoeft</li>
- <li>Matthew Daniel</li>
- <li>Steve Gentle</li>
- <li>Tom Schneider</li>
+<li>New UI</li>
+<li>Separation of GUI and Logic code</li>
+<li>New Plug-in framework for new modules</li>
+<li>Enhanced performance</li>
+<li>Layering of test logic for greater flexibility</li>
+<li>Added support for saving of test elements</li>
+<li>Added support for distributed testing using a single client</li>
</ul>
-<b>Changes:</b>
<h3>Version 1.5.1</h3>
<ul>
<li>Fixed bug that caused cookies not to be read if header name case not as
expected.</li>
@@ -36,7 +32,7 @@
<li>Started work on new framework. New files in cvs, but do not effect program
yet.</li>
<li>Fixed bug that prevent HTTPJMeterThread from delaying according to chosen
timer.</li>
</ul>
-</p>
+
<p>
<h3>Version 1.5</h3>
<ul>
1.3 +78 -62 jakarta-jmeter/xdocs/extending/index.xml
Index: index.xml
===================================================================
RCS file: /home/cvs/jakarta-jmeter/xdocs/extending/index.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- index.xml 2001/03/24 14:39:59 1.2
+++ index.xml 2001/03/24 20:44:24 1.3
@@ -12,15 +12,17 @@
to make this task easier.
</p>
<ul>
- <li>Creating your own Timer</li>
- <li>Creating your own SampleListener (such as a visualizer, or reporter)</li>
- <li>Creating your own Config Element</li>
- <li>Creating your own logic SamplerController</li>
- <li>Creating your own test sample SamplerController</li>
- <li>Creating your own Sampler</li>
- <li>Making your custom elements play nice as a JMeter UI component</li>
- <li>Making your custom elements saveable and loadable from within JMeter</li>
+ <li><a href="#timer">Creating your own Timer</a></li>
+ <li><a href="#listener">Creating your own SampleListener (such as a
visualizer, or reporter)</a></li>
+ <li><a href="#config">Creating your own Config Element</a></li>
+ <li><a href="#logical">Creating your own logic SamplerController</a></li>
+ <li><a href="#testsample">Creating your own test sample
SamplerController</a></li>
+ <li><a href="#sampler">Creating your own Sampler</a></li>
+ <li><a href="#uicomponent">Making your custom elements play nice as a JMeter
UI component</a></li>
+ <li><a href="#saveable">Making your custom elements saveable and loadable from
within JMeter</a></li>
</ul>
+<hr/>
+<a name="timer"/>
<h3>Creating your own Timer</h3>
<p>The timer interface:</p>
<pre>
@@ -30,6 +32,8 @@
long representing the number of milliseconds to delay. The constant timer returns
the
same number every time it's called. A random timer returns a different number each
time.
</p>
+<hr/>
+<a name="listener"/>
<h3>Creating your own SampleListener</h3>
<p>The SampleListener interface:</p>
<pre>
@@ -48,6 +52,8 @@
(ie, they are running and waiting for response, or they're stopped and waiting
to begin again).
</p>
+<hr/>
+<a name="config"/>
<h3>Creating your own Config Element</h3>
<p>The ConfigElement interface:</p>
<pre>
@@ -56,19 +62,19 @@
public Object clone();
</pre>
<p>The ConfigElement interface is sparse. All ConfigElements are expected to
implement
-a public clone method. The reason for this is that config elements will be cloned
+a public <b>clone()</b> method. The reason for this is that config elements will
be cloned
for each different sampling thread, and most will be cloned for each sample. </p>
<p>If your config element expects to be modified in the process of a test run,
and you want those modifications to carry over from sample to sample (as in
a cookie manager - you want to save all cookies that gets set throughout
-the test), then return true for this method. Your config element will not be
+the test), then return true for the <b>expectsModification()</b> method. Your
config element will not be
cloned for each sample. If your config elements are more static in nature,
return false. If in doubt, return false.</p>
-<p>The addConfigElement is required so that config elements can be layered. For
+<p><b>addConfigElement()</b> is required so that config elements can be layered.
For
instance, let's say a user creates a URL entry that contains default values -
they might use this to specify a server. Then, all their test samples configure
individual test cases, but leave out the server field. This information is
combined
-via the addConfigElement method. Your custom config elements should do the right
+via the <b>addConfigElement()</b> method. Your custom config elements should do
the right
thing when this method is called. Normally, this involves ignoring such calls
unless
the passed in ConfigElement is of the same type as yours, and then only merging in
values that are not already set in the object receiving the call (ie you probably
@@ -80,12 +86,12 @@
in your config element. The sampler that uses your config element needs to know
more
about the class than the rest of JMeter - that information is not part of this
interface.
</p>
-<p>If at all possible, extend AbstractConfigElement when creating your own. By
doing so,
+<p>If at all possible, extend <b>AbstractConfigElement</b> when creating your own.
By doing so,
and by following some simple rules, you will get cloning and saving to XML of your
-config element for free (as in, you don't have to do anything!).
AbstractConfigElement
+config element for free (as in, you don't have to do anything!).
<b>AbstractConfigElement</b>
stores all it's values in a Map, and provides getProperty and putProperty methods.
Your
-config element can provide getXXX() and setXXX() methods, but these should delegate
-to getProperty() and setProperty(), probably using static Strings as keys in the
Map.
+config element can provide <b>getXXX()</b> and <b>setXXX()</b> methods, but these
should delegate
+to <b>getProperty()</b> and <b>setProperty()</b>, probably using static Strings as
keys in the Map.
<br/>You can store any type of object, provided the objects are clonable and
Saveable
(Strings, Integer, Long, Double, Float are all good in this regard).
</p>
@@ -95,6 +101,8 @@
have to be converted from a String to an int, so your getXXX() method should check
for this possibility to avoid exceptions.
</p>
+<hr/>
+<a name="logical"/>
<h3>Creating your own logic SamplerController</h3>
<p>The SamplerController interface looks as follows:</p>
<pre>
@@ -108,7 +116,7 @@
contamination between sampling threads.</p>
<p>The <b>nextEntry()</b> method is the essential job of a SamplerController - to
deliver
Entry objects to be sampled. An Entry object encapsulates all the information
needed
-by a Sampler to do its job. The nextEntry() method should work like an iterator
and
+by a Sampler to do its job. The <b>nextEntry()</b> method should work like an
iterator and
continuously return new Entry objects.
</p>
<p>There are two boundary conditions that need to be handled. If the Controller
has no
@@ -141,17 +149,21 @@
<p><b>addConfigElement(ConfigElement config)</b> Your SamplerController should also
be capable of holding configuration elements and adding them to Entries as they
pass through your controller. Again, see GenericController for reference.
Essentially,
-all Entry objects that get returned by nextEntry() are handed all the
ConfigElements
+all Entry objects that get returned by <b>nextEntry()</b> are handed all the
ConfigElements
of the controller.
</p>
-<h3>Creating your own test sample SampleController</h3>
+<hr/>
+<a name="testsample"/>
+<h3>Creating your own test sample SamplerController</h3>
<p>A SamplerController that generates Entry objects is just like a logic controller
except that it creates its own Entry objects instead of gathering them from
-sub-controllers (although, to be fully correct, your test sample SampleController
-should handle both possibilities). Your test sample SampleController can also
+sub-controllers (although, to be fully correct, your test sample SamplerController
+should handle both possibilities). Your test sample SamplerController can also
benefit from extending GenericController. By doing so, most of your cloning and
saving needs are handled (but probably not entirely). See HttpTestSample as
reference.</p>
+<hr/>
+<a name="sampler"/>
<h3>Creating your own Sampler</h3>
<p>The Sampler interface:</p>
<pre>
@@ -160,10 +172,12 @@
<p>Your Sampler has two responsibilities. Of lesser importance, it should do
whatever
it is you want to do, given an Entry object that hopefully contains information
about what is to be sampled. Of greater importance, your sampler should return
-a SampleResult object that holds information about the sampling. Information such
+a <b>SampleResult</b> object that holds information about the sampling.
Information such
as how long the sample took, the text response from the sample (if appropriate),
and
a string that describes the location of what was sampled. The SampleResult
interface
is essentially a Map with public static Strings as keys. </p>
+<hr/>
+<a name="uicomponent"/>
<h3>Making your custom elements play nice as a JMeter UI component</h3>
<p>In order to take part in the JMeter UI, your component needs to implement the
JMeterComponentModel interface:</p>
@@ -175,18 +189,18 @@
public String getClassLabel();
public void uncompile();
</pre>
-<p>Most of this stuff is easy, boring, and tedious. getName(), setName() is a
simple
-String property that is the name of the object. getClassLabel() should return
+<p>Most of this stuff is easy, boring, and tedious. <b>getName()</b>,
<b>setName()</b> is a simple
+String property that is the name of the object. <b>getClassLabel()</b> should
return
a String that describes the class. This string will be displayed to the user and
-so should be short but meaningful. getGuiClass() should return a Class object for
+so should be short but meaningful. <b>getGuiClass()</b> should return a Class
object for
the class that will be used as a GUI component. This class should be a subclass
-of java.awt.Container, and preferably a subclass of javax.swing.JComponent.</p>
+of java.awt.Container, and preferably a subclass of
<b>javax.swing.JComponent</b>.</p>
<p><b>getAddList()</b> should return a list of either Strings or JMenus. These
Strings
represent the Classes that can be added to your SamplerController. Each String
-should correspond to the target class's getClassLabel() String. MenuFactory is
+should correspond to the target class's <b>getClassLabel()</b> String.
<b>MenuFactory</b> is
a class that will return some preset menu lists (such as all available
SamplerControllers,
all available ConfigElements, etc).</p>
-<p><b>uncompile</b> is a cleanup method used between sampling runs. When the user
+<p><b>uncompile()</b> is a cleanup method used between sampling runs. When the
user
hits "Start", JMeter "compiles" the objects in the tree. Child nodes are added
to their parent objects recursively until there is one TestPlan object, which is
then submitted for testing. Afterward, these elements have to un-added from their
@@ -196,25 +210,27 @@
<p>That's it, except for your GUI class. If your SamplerController has no
configuration needs, just return org.apache.jmeter.gui.NamePanel, and the user will
at least be able to change the name of your component. Otherwise, create a gui
class
-that implements the ModelSupported interface:</p>
+that implements the <b>ModelSupported</b> interface:</p>
<pre>
void setModel(Object model);
public void updateGui();
</pre>
-<p>setModel is used to hand your JMeterModelComponent class to the GUI class when
+<p><b>setModel()</b> is used to hand your JMeterModelComponent class to the GUI
class when
it is instantiated. It is your responsibility for providing the means by which
the Gui class updates the values in the model class. For updating in the other
direction, there is <b>updateGui()</b>, which the model class can call if
necessary.
Note, normally, this call is made for you automatically whenever the Gui is brought
-to the screen. If you are creating a Visualizer, then you may need to use
updateGui().
+to the screen. If you are creating a Visualizer, then you may need to use
<b>updateGui()</b>.
For reference, refer to UrlConfigGui (in
org.apache.jmeter.protocol.http.config.gui).</p>
<p>If you have done all this correctly, there's just one more step. If you compile
your classes into the ApacheJMeter.jar file, then you're done. Your classes will
be automatically found and used. Otherwise, you will need to modify
jmeter.properties.
The <i>search_paths</i> property should be modified to include the path where your
classes are. This does not obviate the need for your classes to be in the JVM's
-CLASSPATH - it is an additional requirement. Otherwise, your classes will be
+CLASSPATH - it is an additional requirement. Otherwise, your classes will not be
detected, and the Gui will not make them available to the user.</p>
+<hr/>
+<a name="saveable"/>
<h3>Making your custom elements saveable and loadable from within JMeter</h3>
<p>The Saveable interface has just one method:</p>
<pre>
@@ -222,9 +238,9 @@
</pre>
<p>This method simply returns the Class object that represents the Class that
handles
the saving and loading of your component.</p>
-<p>To write this SaveHandler, make a class that extends TagHandler
+<p>To write this SaveHandler, make a class that extends <b>TagHandler</b>
(from org.apache.jmeter.save.xml). Note, if your component extends
AbstractConfigElement,
-you don't need to do this - provided you only need to save information stored in
+it is already fully Saveable - provided you only have information stored in
the Map from AbstractConfigElement.</p>
<p>To write your own TagHandler, you will have to implement the following
methods:</p>
<pre>
@@ -248,14 +264,14 @@
an XML file. However, there's no standard interface you need to implement, but
rather,
JMeter uses reflection to generate method calls into your class. When JMeter hits
a tag that corresponds to your PrimaryTagName, an instance of your TagHandler will
-be created, and it's setAtts() method will get called. Thereafter, methods are
called
+be created, and it's <b>setAtts()</b> method will get called. Thereafter, methods
are called
depending on subsequent tags and character data. For every tag, JMeter calls
-<tag-name>TagStart(Attributes atts), and for every end tag, JMeter calls
-<tag-name>TagEnd().</p>
+<b><tag-name>TagStart(Attributes atts)</b>, and for every end tag, JMeter
calls
+<b><tag-name>TagEnd()</b>.</p>
<p>Additionally, JMeter will call a method that corresponds to all tags that are
current. So, for instance, if JMeter runs into a tag name "foo", then
<b>foo(Attributes atts)</b> will be called. If JMeter then parses character data,
-then foo(String data) will be called. If JMeter parses a tag within foo, called
+then <b>foo(String data)</b> will be called. If JMeter parses a tag within foo,
called
"nestedFoo", then JMeter will call <b>foo_nestedFoo(Attributes atts)</b> and
<b>foo_nestedFoo(String data)</b>. And so on.
</p>
@@ -270,40 +286,40 @@
{
}
- /**
+ <font color="blue">/**
* Returns the AbstractConfigElement object parsed from the XML. This method
* is required to fulfill the SaveHandler interface. It is used by the XML
* routines to gather all the saved objects.
- */
+ */</font>
public Object getModel()
{
return config;
}
- /**
+ <font color="blue">/**
* This is called when a tag is first encountered for this handler class to
handle.
* The attributes of the tag are passed, and the SaveHandler object is
expected
* to instantiate a new object.
- */
+ */</font>
public void setAtts(Attributes atts) throws Exception
{
String className = atts.getValue("type");
config =
(AbstractConfigElement)Class.forName(className).newInstance();
}
- /**
+ <font color="blue">/**
* Called by reflection when a <property> tag is encountered. Again,
the
* attributes are passed.
- */
+ */</font>
public void property(Attributes atts)
{
currentProperty = atts.getValue("name");
}
- /**
+ <font color="blue">/**
* Called by reflection when text between the begin and end <property>
* tag is encountered.
- */
+ */</font>
public void property(String data)
{
@@ -314,12 +330,12 @@
}
}
- /**
+ <font color="blue">/**
* Called by reflection when the <property> tag is ended.
- */
+ */</font>
public void propertyTagEnd()
{
- // Here's a tricky bit. See below for explanation.
+ <font color="blue">// Here's a tricky bit. See below for
explanation.</font>
List children = xmlParent.takeChildObjects(this);
if(children.size() == 1)
{
@@ -328,17 +344,17 @@
}
- /**
+ <font color="blue">/**
* Gets the tag name that will trigger the use of this object's TagHandler.
- */
+ */</font>
public String getPrimaryTagName()
{
return "ConfigElement";
}
- /**
+ <font color="blue">/**
* Tells the object to save itself to the given output stream.
- */
+ */</font>
public void save(Saveable obj,Writer out) throws IOException
{
AbstractConfigElement saved = (AbstractConfigElement)obj;
@@ -355,9 +371,9 @@
out.write(</ConfigElement>");
}
- /**
+ <font color="blue">/**
* Routine to write each property to xml.
- */
+ */</font>
private void writeProperty(Writer out,String key,Object value) throws
IOException
{
out.write("<property name=\"");
@@ -368,18 +384,18 @@
}
</pre>
<p>
-In the propertyTagEnd method, takeChildObjects() is called on the xmlParent
-instance variable. xmlParent is inherited from TagHandler. It is the
DocumentHandler
+In the <b>propertyTagEnd()</b> method, <b>takeChildObjects()</b> is called on the
xmlParent
+instance variable. xmlParent is inherited from TagHandler - the DocumentHandler
object that is running the show. xmlParent takes an XML file that represents a
portion of
the test configuration tree, and recreates a tree-like data structure. When it is
done, it will convert its tree-like data structure into the test configuration tree
structure.
</p>
<p>However, sometimes, a tree element has sub objects that you do not want
represented
-in the tree - rather, they are objects that are part of your object. But, they may
+in the tree - rather, they are part of your object. But, they may
be complicated enough to warrant their own SaveHandler class, and thus, the
xmlParent
picks them up as part of its tree. When the tag is done, and you know that there
are
-child objects you want to grab, you can call the "takeChildObjects" method and get
a
+child objects you want to grab, you can call the <b>takeChildObjects()</b> method
and get a
List object containing them all. This will remove them from the tree, and you can
add
them to your object that you're creating.
</p>
@@ -388,9 +404,9 @@
code above to save and reload itself from XML. However, one of the pieces of data
that UrlConfig stores is an Arguments object. Arguments is too complicated to save
to file as a simple string, so it has its own Handler object (ArgumentsHandler).
In
-the above code, when the call to JMeterHandler.writeObject(value,out) is made, the
+the above code, when the call to <b>JMeterHandler.writeObject(value,out)</b> is
made, the
writeObject method detects whether the object implements Saveable, and if so, calls
-the object's SaveHandler class to handle saving it. This means, however, that when
+the object's SaveHandler class to deal with it. This means, however, that when
reading that XML file, the Argument object will show up as a separate entity in
the data tree, whereas it originally was just part of the data of the UrlConfig
object. In order to preserve that relationship, it's necessary for the
@@ -398,7 +414,7 @@
objects in the tree, and take them for its own use.
</p>
<p>
-Please study the other SaveHandler objects and the TagHandler class to learn more
+Study the other SaveHandler objects and the TagHandler class to learn more
about how saving is accomplished. Once you understand the design, writing your
own SaveHandler is very easy.
</p>
1.2 +27 -27 jakarta-jmeter/xdocs/user_manual/rmi.xml
Index: rmi.xml
===================================================================
RCS file: /home/cvs/jakarta-jmeter/xdocs/user_manual/rmi.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- rmi.xml 2001/03/20 23:32:09 1.1
+++ rmi.xml 2001/03/24 20:44:24 1.2
@@ -8,22 +8,22 @@
<section name="JMeter over RMI">
<p>
In most real world web application environments the machine running the web
-application is not the machine which is sitting on your desk. However to
-get a true estimate of performance you would like to be measuring the
-true response time of your server, not any (highly variable) network
-bottle-necks that might exist between you and the machine on which your web
-application is running. At the same time using a GUI especially a Java
-GUI over the network is at best painful (using Un*x and X) and at times not
+application is not the machine which is sitting on your desk. However to
+get a true estimate of performance you would like to be measuring the
+true response time of your server, not any (highly variable) network
+bottle-necks that might exist between you and the machine on which your web
+application is running. At the same time using a GUI especially a Java
+GUI over the network is at best painful (using Un*x and X) and at times not
possible (using windows).
</p>
<p>
-To solve this problem JMeter provides a client-server architecture for load
-and performance testing which allows the JMeterEngine (the tester) to
-reside and run on your application server while the configuration GUI and
-visualization executes on the development machine. This offers a number
+To solve this problem JMeter provides a client-server architecture for load
+and performance testing which allows the JMeterEngine (the tester) to
+reside and run on your application server while the configuration GUI and
+visualization executes on the development machine. This offers a number
of features:
<ul>
- <li>True performance measurment without network bottlenecks</li>
+ <li>True performance measurment without network bottlenecks</li>
<li>Fast responsive GUI</li>
<li>Saving of test samples to a local machine</li>
<li>Managment of multiple JMeterEngines from a single machine</li>
@@ -32,27 +32,27 @@
</section>
<section name="Running the JMeter engine on the server">
<p>
-Follow the <a href="installing.html">instructions</a> for installing
-JMeter. Once JMeter is sucessfully installed you will need to put the
-<code>.../JMeter1.6/bin/ApacheJMeter.jar</code> into your
-<code>CLASSPATH</code> environment variable and execute
-<code>rmiregistry</code>. Once the RMI registry is started you will need
-to start the actual JMeterServer. To do this run the
-<code>jmeter-server</code> (Un*x) or <code>jmeter-server.bat</code>
-script (windows) to start the server. Your server should now be started,
+Follow the <a href="installing.html">instructions</a> for installing
+JMeter. Once JMeter is sucessfully installed you will need to put the
+<code>.../JMeter1.6/bin/ApacheJMeter.jar</code> into your
+<code>CLASSPATH</code> environment variable and execute
+<code>rmiregistry</code>. Once the RMI registry is started you will need
+to start the actual JMeterServer. To do this run the
+<code>jmeter-server</code> (Un*x) or <code>jmeter-server.bat</code>
+script (windows) to start the server. Your server should now be started,
to test it follow the instructions for running the JMeter client.
</p>
</section>
<section name="Running the JMeter client">
<p>
-Once JMeter is sucessfully installed you need to modify the
-<code>jmeter.properties</code> file in the bin directory. Change the
-<code>remote_hosts</code> property to include the address of your server.
-Next run <code>jmeter-client</code> (Un*x) or
-<code>jmeter-client.bat</code> (windows) to connect to the JMeter Engine.
-If everything works as planned you will be connected with the JMeter
-Engine and JMeter will behave exactly as if you were running it all
-locally. See the <a href="user_manual/index.html">user manual</a> for
+Once JMeter is sucessfully installed you need to modify the
+<code>jmeter.properties</code> file in the bin directory. Change the
+<code>remote_hosts</code> property to include the address of your server.
+Next run <code>jmeter</code> (Un*x) or
+<code>jmeter.bat</code> (windows) to connect to the JMeter Engine.
+If everything works as planned you will be connected with the JMeter
+Engine and JMeter will behave exactly as if you were running it all
+locally. See the <a href="user_manual/index.html">user manual</a> for
detailed instructions.
</p>
</section>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
