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]
