Date: 2004-08-29T08:06:17
Editor: J�rgWeinmann <[EMAIL PROTECTED]>
Wiki: Apache JMeter Wiki
Page: JMeterRemoteTestingEnhancements
URL: http://wiki.apache.org/jakarta-jmeter/JMeterRemoteTestingEnhancements
no comment
Change Log:
------------------------------------------------------------------------------
@@ -1,6 +1,6 @@
'''Navigation trail:''' ["JMeterProjectPages"] - ["JMeterDevelopment"] -
["JMeterDevelopment"]/LongTerm
----
-<strong>How can we improve the remote testing experience?</strong>
+= How can we improve the remote testing experience? =
* Documentation of remote testing does not provide details of the ports that need
to be open on a firewall
* Make remote testing easier and less error prone (provide shell scripts for
rmiregistry or do not use RMI at all) -- OliverRossmueller 2003-01-06
@@ -14,7 +14,7 @@
* Could enter the address of the server here and eliminate the remote_hosts
setting in jmeter.properties.
* Good thoughts - maybe a dialog box could provide a bunch of controls associated
with starting a remote host - ie IP address, custom user-defined variables for that
run, etc.
----
-'''{ { { RMI/Firewall } } } issues'''
+= RMI/Firewall issues =
In the list above are some points regarding firewall configuration and the need for
tunneling RMI through a firewall. To make these requirements more clear can anyone
please give an example of why it is necessary to use a remote JMeter server BEHIND a
firewall and why it is not possible in that situation to use a JMeter server IN FRONT
of the firewall. -- OliverRossmueller
@@ -29,15 +29,14 @@
* So this provides the example you requested above? Why not just control them
through an enhanced remote server manager UI within JMeter itself (basically what this
page is all about) and tunnel the RMI. -- ScottEade 2003-01-16
* I was not sure why you would need RMI tunneling, but this scenario makes
sense to me and RMI tunneling is one way to make it work. Do you know of any RMI
tunneling implementation that fits with the Apache Licenses so we could use it for
JMeter? -- OliverRossmueller
All in all it is nothing like the issue I originally imagined it to be. -- ScottEade
2003-01-16
-
-Remote Testing Set Up using Rendezvous
--------------------------------------
+= Remote Testing Set Up using Rendezvous =
It would be really nice to use some of the ZeroConf technology that is become more
and more proliferate now to automatically discover the remote servers available to
control on a network. I know there is a module called JRendezvous which is an
implementation of Rendezvous (Apple's brand name for ZeroConf) that could be used.
Imagine how nice it would be to run up your remote servers, then click a menu in your
client GUI and automatically see the various remote servers that are avilable. Its one
last thing to fight with when trying to get this set up. Also looks a little more
polished.
...although, saying this, it may be more useful if the GUI could cut and paste nodes
first (let's run before we can walk) -- Craig Pugsley 12/3/03
----
-<strong>Serialisation</strong>
+= Serialisation =
At present, when a script is sent to the remote server for execution, AFAIK the
entire tree is serialised and reconstructed at the other end. This places a lot of
burden on developers to make sure that objects are serialisable. Since there is
already a convenient representation for a test (i.e. the JMX format) it seems to me
that we should make use of it and ship that across instead. It would mean that the
remote installation would need to have all the appropriate classes present, but that
is probably true anyway. It should reduce the amount of data sent. It would probably
get rid of some of the incompatibilities that occur. I read somewhere recently
(probably Effective Java by Joshua Bloch) that hash values are not _guaranteed_ to be
the same for different JVMs, nor even between runs of a JVM, which might explain some
problems users have reported.["sebb"]
Similar considerations apply to the Sample data that is returned, and it would be
useful to be able to batch this and/or just send back aggregrate data during a test
run, and allow the client to request the full data when required.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
