Welcome!

== 

I'm not sure I understand how the JMeter server instances would know
when to send their IP address back to the client, unless the client is
started before any of the servers.

In which case, how does the client know when all the servers are ready for use?

==

Note:
The current JMeter server-client implementation is not all that
scalable, as all the samples have to be returned to the controlling
JMeter instance.

If you are expecting to generate heavy traffic, you will probably find
that the controlling instance becomes a bottleneck. Or even the
network link may become saturated.

==

The controlling instance obtains the list of node names or IP
addresses from a property, and can be asked to start a test on one or
all of the nodes in the list.

So perhaps another approach would be to preset the list to all
possible remote nodes, but allow some of the remote nodes to be
absent.

S.

On Thu, 27 Jan 2005 15:46:45 -0600, Hurley Kevin - khurle
<[EMAIL PROTECTED]> wrote:
> Hey Guys,
> 
> I am brand new to this list. This is my first message.
> 
> I was thinking about suggesting an enhancement to the remote engine piece of
> JMeter server.
> 
> (See code example question below)
> 
> I am currently working in a grid environment. My company uses a cluster of
> grid "nodes" in order to facilitate processing batch and real-time
> transactions. I have been tasked with benchmarking web services transactions
> running through our grid. I recently built a software router to handle
> subscriptions to a load-balancer (BigIP - F5). So, my first task with JMeter
> will be to benchmark the registration/withdrawal of subscriptions through
> this setup.
> 
> One of the problems that presents itself to me is that - all grid nodes are
> "hands-off" to users of the grid. In other words, the only control over a
> grid node is through a web page (or 'generic' user). There is no way to
> manually log on to the grid node. Also, since the grid nodes rely on NFS
> shares to read-write to/from files (unsuggested), there is no good way to
> maintain a list of all grid nodes belonging to one "cluster", as nodes
> come-up and go-down.
> 
> My plan is to set up many nodes that will serve as remote JMeter engines. In
> my situation, it would be beneficial to me to allow the controlling client
> (gui) to automatically "discover" all nodes and their ip addresses as
> participants in the remote pool of servers. This way - I don't have to jump
> through hoops to setup all the ip addresses from all the remote servers in
> the controllers property file.
> 
> I am currently trying to discover how the remote server portion of the code
> works exactly.
> 
> I have noticed in the class:"RemoteJMeterEngineImpl.java"
> that there is a method, " public void setHost(String host)".
> 
> Does this method get called during the client setup or during the remote
> servers' setup?
> 
> How about having the Remote server discover its own IP address....i.e.
> 
>     InetAddress local = InetAddress.getLocalHost();
>     _hostname = local.getHostAddress();
> 
> ...instead of just the name of the host. (NOTE: the above code retrieves the
> actual ip address)
> 
> Then, after the remote server discovers its ipaddress, it could "push" it to
> the controlling client - whose address is specified in a deployed property
> file.
> 
> So the idea is - deploy a JMeter remote engine along with a property/config
> file containing the controlling clients ip address....and then have all the
> remote servers "push" their ip address back to the (already running) client.
> 
> Any thoughts about this suggestion?
> 
> Thank you for your patience
> 
> Kevin Hurley
> Software Developer
> Acxiom Corp.
> 
> **********************************************************************
> The information contained in this communication is
> confidential, is intended only for the use of the recipient
> named above, and may be legally privileged.
> If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination,
> distribution, or copying of this communication is strictly
> prohibited.
> If you have received this communication in error,
> please re-send this communication to the sender and
> delete the original message or any copy of it from your
> computer system. Thank You.
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to