I apoligize for not following this thread completely so I'm not sure if this "helps" in any way...
The method a certain other tool uses is to have all of the servers listening on a particular port. When the controller starts, he broadcasts an are-you-there-message on that port and waits for any replies. Then the user picks from the servers that replied to run the test(s) on. J ----- Original Message ----- From: "sebb" <[EMAIL PROTECTED]> To: "JMeter Developers List" <[email protected]> Sent: Friday, January 28, 2005 2:31 PM Subject: Re: Remote Server discovery > On Fri, 28 Jan 2005 09:44:16 -0600, Hurley Kevin - khurle > <[EMAIL PROTECTED]> wrote: > > Sebb, > > > > Thanks for your response. > > > > I am assuming that the controller would be started previous to starting the > > remote instances. > > OK. > > > Once a remote instance comes up, it "registers" with the controller (by > > writing its ip address to the property file and being listed in the gui > > menu). Only the engineer of the test knows when all the remote instances > > have been registered (by looking at the list). > > > > This method is not completely "clean", but workable. > > OK > > > The biggest problem with that behavior I can imagine would be that the > > client "dies" before all the remote instances come up...of course in that > > case the engineer running the test would know that some remote instancesare > > missing... > > > > If the client dies, then he'd have to start again, surely? > > > === > > > > The bottleneck issue scares me. I didn't think that the "controlling client" > > had that much to wait on. I assumed that the remote instances would generate > > a sample and "drop-it-off" to the controller - only to continue processing > > with or without acknowlegement from the client side. > > The Listeners in the client are connected using RMI to the > corresponding Listeners in each server. Each Listener is handled > separately. I think all Listeners are called in turn by the JMeter > engine after every sample. So the servers currently need to get the > response from the client before continuing. > > There has been some work done in the remote Listener interface to > allow samples to be recorded locally and passed back later, but I > think the solution uses a memory array, which means it's not suitable > for tests with lots of samples. > > Also, I presume RMI adds quite an overhead to the data being returned. > > For minimal resource usage, one can run multiple test plans in batch > (non-GU) mode, and combine the output log files later, which is easy > enough when using CVS output. It helps if the timestamps are > consistent ! (but this is true also for client-server mode). > > You may find that you only need one or two non-GUI clients to generate > enough load, assuming the network is up to it. > > > > > ==== > > > > The approach of pre-setting all the nodes in the list is prohibitive for me. > > How many nodes are there? > > > Kevin > > > > > > -----Original Message----- > > From: sebb [mailto:[EMAIL PROTECTED] > > Sent: Friday, January 28, 2005 8:15 AM > > To: JMeter Developers List > > Subject: Re: Remote Server discovery > > > > 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] > > > > --------------------------------------------------------------------- > > 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]
